* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-12 5:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sam Vilain, Jakub Narebski, Paolo Bonzini, git
In-Reply-To: <alpine.LFD.1.10.0809111641110.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>On Fri, 12 Sep 2008, Sam Vilain wrote:
>It can happen even without any conflicts, just because the context
>changed. So it really isn't about merge conflicts per se, just the fact
>that a patch can change when it is applied in a new area with a three-way
>diff - or because it got applied with fuzz.
Quite.
>You could add it as a
> Original-patch-id: <sha1>
That will probably work fine when operating locally on (short) temporary
branches.
It would probably become computationally prohibitive to use it between
long lived permanent branches. In that case it would need to be
augmented by the sha1 of the originating commit. Which gives you two
hashes as reference, and in that case you might as well use the two
commit hashes of which the difference yields the patch.
--
Sincerely,
Stephen R. van den Berg.
"Father's Day: Nine months before Mother's Day."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-12 5:39 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Jakub Narebski, Nicolas Pitre, Theodore Tso, Linus Torvalds, git
In-Reply-To: <48C9B830.2060903@gmail.com>
A Large Angry SCM wrote:
>Stephen R. van den Berg wrote:
>>Jakub Narebski wrote:
>>>Stephen R. van den Berg wrote:
>>>>Well, the principle of least surprise dictates that they should be kept
>>>>by gc as described above, however...
>>>>I can envision an option to gc say "--drop-weak-links" which does
>>>>exactly what you describe.
>>>Well, IIRC the need for this was one of the causes of "death" of 'prior'
>>>header link proposal...
>>As I understood it, one of the causes of death of the "prior" link
>>proposal was that it was unclear if it pulled in the linked-to commits
>>upon fetch. In the "origin" case, the default is *not* to fetch them.
>And that's WRONG. Both prior and origin must fetch them if they're
>reference in the header.
By definition of the origin headerfield that is not wrong, there are no
other rules. But the point is moot at the moment, since I'm going to
create a proof of concept which puts the field in the free-form trailer.
--
Sincerely,
Stephen R. van den Berg.
"Father's Day: Nine months before Mother's Day."
^ permalink raw reply
* configuring git public repository
From: sagi4 @ 2008-09-12 4:47 UTC (permalink / raw)
To: git
Hi all,
I am new git..
I would like to configure git as a public repository for my rails
application..
Please help me..
Thanks
Sg..
--
View this message in context: http://www.nabble.com/configuring-git-public-repository-tp19449377p19449377.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Teach git.el to mark/unmark files by regexp
From: David Christensen @ 2008-09-12 4:22 UTC (permalink / raw)
To: git; +Cc: julliard, gister, David Christensen
In-Reply-To: <1221193324-59334-1-git-send-email-david@endpoint.com>
Adds the functions git-mark-regexp and git-unmark-regexp to git.el.
Creates a mark-map keymap to support dired-like behavior for
marking/unmarking via regexp. Also adds these functions to the
menubar.
Signed-off-by: David Christensen <david@endpoint.com>
---
contrib/emacs/git.el | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 580652c..a982fbe 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -950,14 +950,18 @@ Return the list of files that haven't been handled."
(when goal-column (move-to-column goal-column)))
(defun git-mark-regexp (re)
- "Mark all files which match a provided regexp."
- (interactive "sMark files matching regular expression: ")
+ "Mark all files which match a provided regexp. With prefix argument, unmark files which match."
+ (interactive
+ (list
+ (read-from-minibuffer (if current-prefix-arg "Unmark files matching regular expression: " "Mark files matching regular expression: "))))
(unless git-status (error "Not in git-status buffer."))
- (ewoc-map (lambda (info) (unless (git-fileinfo->marked info)
- (when (string-match re (git-fileinfo->name info))
- (setf (git-fileinfo->marked info) t)))) git-status)
- ; move back to goal column after invalidate
- (when goal-column (move-to-column goal-column)))
+ (if current-prefix-arg
+ (git-unmark-regexp re)
+ (ewoc-map (lambda (info) (unless (git-fileinfo->marked info)
+ (when (string-match re (git-fileinfo->name info))
+ (setf (git-fileinfo->marked info) t)))) git-status)
+ ; move back to goal column after invalidate
+ (when goal-column (move-to-column goal-column))))
(defun git-unmark-regexp (re)
"Unmark all files which match a provided regexp."
@@ -1504,7 +1508,12 @@ amended version of it."
(define-key toggle-map "m" 'git-toggle-all-marks)
; the mark submap
(define-key mark-map "%" 'git-mark-regexp)
- (define-key mark-map "\C-?" 'git-unmark-regexp)
+ (define-key mark-map "m" 'git-mark-file)
+ (define-key mark-map "u" 'git-unmark-file)
+ (define-key mark-map "t" 'git-toggle-all-marks)
+ (define-key mark-map "!" 'git-unmark-all)
+ (define-key mark-map "?" 'git-unmark-all)
+ (define-key mark-map "\C-?" 'git-unmark-file-up)
(setq git-status-mode-map map))
(easy-menu-define git-menu git-status-mode-map
"Git Menu"
--
1.6.0.1.90.g27a6e.dirty
^ permalink raw reply related
* [PATCH v2] Teach git.el to mark/unmark files by regexp
From: David Christensen @ 2008-09-12 4:22 UTC (permalink / raw)
To: git; +Cc: julliard, gister
In-Reply-To: <F0D63233-0302-4CF8-9CE1-FC12F2B80F91@endpoint.com>
Teaches git-mark-regexp to respect a prefix argument as an indication
to unmark files. Also adds other dired-like key bindings.
^ permalink raw reply
* git-svn: file not found in commit
From: mriou @ 2008-09-12 2:48 UTC (permalink / raw)
To: git
Hi,
I'm trying to import with git-svn an Apache repository located at:
http://svn.eu.apache.org/repos/asf/ode
Doing so, at some point git-svn seems to get lost when identifying a parent:
r563284 = 1e889810d5344e1222077f4026b028a922826d45 (trunk)
Found possible branch point:
https://svn.eu.apache.org/repos/asf/ode/trunk/tasks =>
https://svn.eu.apache.org/repos/asf/ode/branches/bart, 563283
Initializing parent: bart@563283
W: Ignoring error from SVN, path probably does not exist: (175007): HTTP
Path Not Found: '/repos/asf/!svn/bc/10001/ode/trunk/tasks' path not found
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
branch_from: /incubator/ode => /incubator/ode/trunk/tasks
Found possible branch point:
https://svn.eu.apache.org/repos/asf/incubator/ode/trunk/tasks =>
https://svn.eu.apache.org/repos/asf/ode/trunk/tasks, 560672
Initializing parent: bart@560672
Found branch parent: (bart@563283) 69e8e3436d6572333b81a2c12cb6d3db8d4780a7
Following parent with do_switch
Successfully followed parent
r560673 = 7bf3908aca6fccf484f7dd806e57292400600f70 (bart@563283)
D hibernate.rake
D cobertura.rake
D jdepend.rake
jbi.rake was not found in commit 7bf3908aca6fccf484f7dd806e57292400600f70
(r560673)
The error message is correct, that revision didn't contain this file, it's
been added much later. So the parent identification seems to be getting it
wrong. And I have to agree the logs are confusing around that revision:
$ svn log -r 563283:563286 --verbose https://svn.apache.org/repos/asf/
------------------------------------------------------------------------
r563283 | mszefler | 2007-08-07 00:19:24 +0300 (Tue, 07 Aug 2007) | 2 lines
Changed paths:
D /ode/branches/bart
Remove.
------------------------------------------------------------------------
r563284 | mszefler | 2007-08-07 00:19:32 +0300 (Tue, 07 Aug 2007) | 2 lines
Changed paths:
A /ode/branches/bart (from /ode/trunk/tasks:563283)
D /ode/trunk/tasks
Moved.
------------------------------------------------------------------------
r563285 | mszefler | 2007-08-07 00:20:11 +0300 (Tue, 07 Aug 2007) | 2 lines
Changed paths:
A /ode/trunk/tasks (from /ode/branches/bart:563284)
copyied back.
------------------------------------------------------------------------
r563286 | mszefler | 2007-08-07 00:21:57 +0300 (Tue, 07 Aug 2007) | 2 lines
Changed paths:
A /ode/branches/bart/tasks (from /ode/trunk/tasks:563285)
copied.
------------------------------------------------------------------------
So my questions are the following:
- is there a way I can help git svn finding the correct ancestor?
- is there a way I can ask git svn to ignore ancestors only when it fails?
If the answer is no in both cases, maybe I could add a switch to ignore
those errors?
Thanks,
Matthieu
--
View this message in context: http://www.nabble.com/git-svn%3A-file-not-found-in-commit-tp19448485p19448485.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Sam Vilain @ 2008-09-12 2:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jakub Narebski, Paolo Bonzini, Stephen R. van den Berg, git
In-Reply-To: <alpine.LFD.1.10.0809111641110.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> On Fri, 12 Sep 2008, Sam Vilain wrote:
>> 2. make git-cherry-pick have a similar option to '-x', but instead of
>> recording the original commit ID, record the original *patch* ID,
>> *if* there was a merge conflict for that cherry pick.
>
> Actually, don't make it dependent on merge conflicts. Just make it depend
> on whether the patch ID is _different_.
>
> It can happen even without any conflicts, just because the context
> changed. So it really isn't about merge conflicts per se, just the fact
> that a patch can change when it is applied in a new area with a three-way
> diff - or because it got applied with fuzz.
>
> You could add it as a
>
> Original-patch-id: <sha1>
>
> or something. And then you just need to teach "git cherry/rebase" to take
> both the original ID and the new one into account when deciding whether it
> has already seen that patch.
Yes, right - it's the patch ID changing that's the problem for
git-cherry / rev-list --cherry-pick to be able to spot changes as the
'same'.
Someone else pointed out that git-rebase -i might want to have this as well.
I actually looked into coding this, but there was a little problem with
the way git-revert worked - it builds the commit message before the diff
is calculated. So there would probably need to be a little trivial
refactoring first before this can be implemented.
Sam.
^ permalink raw reply
* Re: [JGIT PATCH 1/2] Issue 23: Resolve tag^0 as tag^{commit}
From: Imran M Yousuf @ 2008-09-12 1:51 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Robin Rosenberg, Shawn O. Pearce, git, Imran M Yousuf
In-Reply-To: <20080912000007.GA31931@diku.dk>
On Fri, Sep 12, 2008 at 6:00 AM, Jonas Fonseca <fonseca@diku.dk> wrote:
>> Second, the testcase in the second patch fails on my machine.
>>
>> testDerefTaggedTagTree(org.spearce.jgit.lib.T0008_testparserev)
>> junit.framework.ComparisonFailure: expected:<[269e1253bad5c247c6bde37aa48ae1e03138206c]> but was:<[be83157b4ffe650d728ba4f98ad47b623b0d0c20]>
>> at junit.framework.Assert.assertEquals(Assert.java:81)
>> at junit.framework.Assert.assertEquals(Assert.java:87)
>> at org.spearce.jgit.lib.T0008_testparserev.testDerefTaggedTagTree(T0008_testparserev.java:123)
>
> I reran all the test before formatting the patch, but after doing some
> last minut changes. When I run all the tests using maven (inside
> NetBeans or from the command line) it tells me:
>
> Tests run: 428, Failures: 0, Errors: 0, Skipped: 0
>
> From the output it looks like the tests in the files named T000* are
> never run. However, where the breakage is (could be my setup) I don't
> know. Imran?
>
Hmm, I will have to check it. Will come back with some feedback after
checking. Usually if a class is a TestCase then it should have run.
> Anyway, for now I will just run the single test specifically. Perhaps I
> should just put this into the same patch. Anyway, the following should
> fix it.
>
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
> index 2a1a4ad..1fc73b4 100644
> --- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
> @@ -117,7 +117,7 @@ public void testDerefTagIssue23() throws IOException {
> }
>
> public void testDerefTaggedTagTree() throws IOException {
> - assertEquals("269e1253bad5c247c6bde37aa48ae1e03138206c",db.resolve("refs/tags/C").name());
> + assertEquals("be83157b4ffe650d728ba4f98ad47b623b0d0c20",db.resolve("refs/tags/C").name());
> assertEquals("d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864",db.resolve("refs/tags/C^{commit}").name());
> assertEquals("856ec208ae6cadac25a6d74f19b12bb27a24fe24",db.resolve("refs/tags/C^{tree}").name());
> }
>
> --
> Jonas Fonseca
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: new upstream rebase recovery section in git-rebase
From: Marcus Griep @ 2008-09-12 1:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1221147525-5589-2-git-send-email-trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
Thomas Rast wrote:
> +Now suppose the 'subsystem' maintainer decides to clean up his history
> +with an interactive rebase. He edits commits A and D (marked with a
> +`*`), decides to remove D entirely and moves B to the front. This
> +results in
Minor correction:
-+with an interactive rebase. He edits commits A and D (marked with a
++with an interactive rebase. He edits commits A and C (marked with a
> +To fix this, you have to manually transplant your own part of the
> +history to the new branch head. Looking at `git log`, you should be
> +able to determine that three commits on 'topic' are yours. Again
> +assuming you are already on 'topic', you can do
> +------------
> + git rebase --onto subsystem HEAD~3
> +------------
> +to put things right. Of course, this again ripples onwards:
> +'everyone' downstream from 'subsystem' will have to 'manually' rebase
> +all their work!
I like this documentation because it provides another clear case of how
the '--onto' option is used.
--
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: A Large Angry SCM @ 2008-09-12 0:30 UTC (permalink / raw)
To: Stephen R. van den Berg
Cc: Jakub Narebski, Nicolas Pitre, Theodore Tso, Linus Torvalds, git
In-Reply-To: <20080911202228.GG1451@cuci.nl>
Stephen R. van den Berg wrote:
> Jakub Narebski wrote:
>> Stephen R. van den Berg wrote:
>>> Well, the principle of least surprise dictates that they should be kept
>>> by gc as described above, however...
>>> I can envision an option to gc say "--drop-weak-links" which does
>>> exactly what you describe.
>
>> Well, IIRC the need for this was one of the causes of "death" of 'prior'
>> header link proposal...
>
> As I understood it, one of the causes of death of the "prior" link
> proposal was that it was unclear if it pulled in the linked-to commits
> upon fetch. In the "origin" case, the default is *not* to fetch them.
And that's WRONG. Both prior and origin must fetch them if they're
reference in the header.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-12 0:13 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <48C9B1C8.9070007@gmail.com>
A Large Angry SCM wrote:
>Stephen R. van den Berg wrote:
>>No it does not.
>>The cryptographic seal is calculated over the content of the commit,
>>which includes the hashes of all referenced objects, but doesn't include
>>the objects themselves.
>>The content of the commit is not violated.
>The fetch MUST gather the referenced objects ALWAYS or I can't verify
>the history. To do otherwise means that ID strings on the origin lines
>are nothing more than an arbitrary text tag and not pointer to a
>specific history.
To fetch, by default, the origin lines *are* nothing more than arbitrary
text and not a pointer to a specific history.
>How do I verify (think git-fsck) that what the origin lines refer to
>are, in fact, commits with the proper relationships? Either they HAVE to
>be in the repository or the references do not belong in the header.
If the origin hashes are not reachable, then fsck is required to silently
skip them, according to spec.
If the origin hashes *are* reachable, then fsck is required to verify
that they refer to proper commits with a normal history.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: A Large Angry SCM @ 2008-09-12 0:03 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <20080911123902.GB2056@cuci.nl>
Stephen R. van den Berg wrote:
> A Large Angry SCM wrote:
>> Stephen R. van den Berg wrote:
>>> If you fetch just branches A, B and C, but not D, the origin link from A
>>> to D is dangling.
>
>> I do not understand how this can be considered an acceptable behavior.
>> If an object ID is referenced in an object header, particularly commit
>> objects, fetch must gather those objects also because to do otherwise
>> breaks the cryptographic authentication in git.
>
> No it does not.
> The cryptographic seal is calculated over the content of the commit,
> which includes the hashes of all referenced objects, but doesn't include
> the objects themselves.
> The content of the commit is not violated.
The fetch MUST gather the referenced objects ALWAYS or I can't verify
the history. To do otherwise means that ID strings on the origin lines
are nothing more than an arbitrary text tag and not pointer to a
specific history.
>
> Do not forget though:
> - origin links are a rare occurrence.
> - When they occur, they usually were made to point into other (deemed)
> important public branches.
> - Due to the fact that the branches they are pointing into are important
> and public, in most cases the origin links *will* point to objects you
> actually already have (even if you fetched from someone else).
> - The only time you're going to have dangling origin links is when
> they were pointing at someone's private branches, in which case it was
> not very prudent of the committer to actually record the link in the
> first place. But nothing breaks if you don't have his private branch
> locally.
How do I verify (think git-fsck) that what the origin lines refer to
are, in fact, commits with the proper relationships? Either they HAVE to
be in the repository or the references do not belong in the header.
^ permalink raw reply
* Re: [JGIT PATCH 1/2] Issue 23: Resolve tag^0 as tag^{commit}
From: Jonas Fonseca @ 2008-09-12 0:00 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git, Imran M Yousuf
In-Reply-To: <200809120047.58484.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote Fri, Sep 12, 2008:
> torsdagen den 11 september 2008 23.39.27 skrev Jonas Fonseca:
> > Repository.resolve("tag^0") failed with "not a commit". Fix it and add a
> > test case for it.
>
> It seems this case is not *that* special. It is tag^N == tag^{commit}^N
> Same for tag~N == tag^{commit}~N-
git-rev-parse(1) says:
· A suffix ^ to a revision parameter means the first parent of that
commit object. ^<n> means the <n>th parent (i.e. rev^ is
equivalent to rev^1). As a special rule, rev^0 means the commit
itself and is used when rev is the object name of a tag object that
refers to a commit object.
but does take tag^1, however not tag^2. It looks like tag~N is broken in
JGit ("not a commit") so should also be fixed if we want to be
compatible with git-rev-parse.
BTW, I just noticed that ^{} is not handled correctly either for tags.
· A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{}) means
the object could be a tag, and dereference the tag recursively
until a non-tag object is found.
Only one derefence is performed.
> My fault, i guess, but it would be nice of you fixed it while you are at it.
I will try to make fixes for the above cases tomorrow.
> Second, the testcase in the second patch fails on my machine.
>
> testDerefTaggedTagTree(org.spearce.jgit.lib.T0008_testparserev)
> junit.framework.ComparisonFailure: expected:<[269e1253bad5c247c6bde37aa48ae1e03138206c]> but was:<[be83157b4ffe650d728ba4f98ad47b623b0d0c20]>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at org.spearce.jgit.lib.T0008_testparserev.testDerefTaggedTagTree(T0008_testparserev.java:123)
I reran all the test before formatting the patch, but after doing some
last minut changes. When I run all the tests using maven (inside
NetBeans or from the command line) it tells me:
Tests run: 428, Failures: 0, Errors: 0, Skipped: 0
From the output it looks like the tests in the files named T000* are
never run. However, where the breakage is (could be my setup) I don't
know. Imran?
Anyway, for now I will just run the single test specifically. Perhaps I
should just put this into the same patch. Anyway, the following should
fix it.
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
index 2a1a4ad..1fc73b4 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
@@ -117,7 +117,7 @@ public void testDerefTagIssue23() throws IOException {
}
public void testDerefTaggedTagTree() throws IOException {
- assertEquals("269e1253bad5c247c6bde37aa48ae1e03138206c",db.resolve("refs/tags/C").name());
+ assertEquals("be83157b4ffe650d728ba4f98ad47b623b0d0c20",db.resolve("refs/tags/C").name());
assertEquals("d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864",db.resolve("refs/tags/C^{commit}").name());
assertEquals("856ec208ae6cadac25a6d74f19b12bb27a24fe24",db.resolve("refs/tags/C^{tree}").name());
}
--
Jonas Fonseca
^ permalink raw reply related
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 23:49 UTC (permalink / raw)
To: Miklos Vajna
Cc: Jeff Whiteside, Elijah Newren, Changsheng Jiang, Git Mailing List
In-Reply-To: <20080911233941.GP4829@genesis.frugalware.org>
On Thu, Sep 11, 2008 at 4:39 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Sep 11, 2008 at 02:24:51PM -0700, Eric Raible <raible@gmail.com> wrote:
>> My question is why "git reset --hard" can't make a special case for
>> _newly added_ tracked files. After all, "git status" knows that they're
>> "new files", and "git reset --hard" could realize that wiping them off
>> the face of the earth isn't the most helpful thing possible.
>
> I rarely need this, but I use 'git read-tree -m HEAD' before git reset
> --hard in case I want such a behaviour.
What advantages does "git read-tree -m HEAD" have over "git reset" or
"git rm --cached <file list>"?
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-11 23:44 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jakub Narebski, Paolo Bonzini, Stephen R. van den Berg, git
In-Reply-To: <48C9A9A4.8090703@vilain.net>
On Fri, 12 Sep 2008, Sam Vilain wrote:
>
> 2. make git-cherry-pick have a similar option to '-x', but instead of
> recording the original commit ID, record the original *patch* ID,
> *if* there was a merge conflict for that cherry pick.
Actually, don't make it dependent on merge conflicts. Just make it depend
on whether the patch ID is _different_.
It can happen even without any conflicts, just because the context
changed. So it really isn't about merge conflicts per se, just the fact
that a patch can change when it is applied in a new area with a three-way
diff - or because it got applied with fuzz.
You could add it as a
Original-patch-id: <sha1>
or something. And then you just need to teach "git cherry/rebase" to take
both the original ID and the new one into account when deciding whether it
has already seen that patch.
Linus
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Miklos Vajna @ 2008-09-11 23:39 UTC (permalink / raw)
To: Eric Raible
Cc: Jeff Whiteside, Elijah Newren, Changsheng Jiang, Git Mailing List
In-Reply-To: <279b37b20809111424y73a3f6b9xe7f5019b9ba0da16@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
On Thu, Sep 11, 2008 at 02:24:51PM -0700, Eric Raible <raible@gmail.com> wrote:
> My question is why "git reset --hard" can't make a special case for
> _newly added_ tracked files. After all, "git status" knows that they're
> "new files", and "git reset --hard" could realize that wiping them off
> the face of the earth isn't the most helpful thing possible.
I rarely need this, but I use 'git read-tree -m HEAD' before git reset
--hard in case I want such a behaviour.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Theodore Tso, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809111533110.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>I have asked several times what it is that makes it so important that the
>"origin" information be in the headers. Nobody has been able to explain
>why it's so different from just doing it in the free-form part. NOBODY.
That's because the difference is small:
In the header is slightly faster and more elegant (both designwise and
displaywise), that's it.
Other than that, it hardly matters.
>The only thing I have ever argued against is adding commit headers that
>have no sane semantics and don't make sense as internal git data
>structures.
Of course.
In any case, I think I got enough feedback from the list to create
a working implementation/concept which is going to use the free-form
trailer to implement the origin field.
--
Sincerely,
Stephen R. van den Berg.
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 23:29 UTC (permalink / raw)
To: Jeff Whiteside; +Cc: Junio C Hamano, git
In-Reply-To: <3ab397d0809111604r5d9dda04p32a987208d1fa92d@mail.gmail.com>
On Thu, Sep 11, 2008 at 4:04 PM, Jeff Whiteside
<jeff.m.whiteside@gmail.com> wrote:
> And if you want to delete all untracked files
> ls | sed s/`git status --index --filenamesonly`//g | rm
> ls | sed s/`git status --commitrepo --filenamesonly`//g | rm
> (I realize those commands don't actually work, but I'm a noob.)
"git clean" will remove untracked files.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Sam Vilain @ 2008-09-11 23:28 UTC (permalink / raw)
To: Jakub Narebski
Cc: Linus Torvalds, Paolo Bonzini, Stephen R. van den Berg, git
In-Reply-To: <200809101823.22072.jnareb@gmail.com>
Jakub Narebski wrote:
>> And that dotted line really does sound like something you could do with
>> just the existing "hyperlink" functionality in the commit message.
>
> As far as I understand (note: I'm neither for, nor against the proposal;
> although I think it has thin chance to be accepted, especially soon),
> it is for graphical history viewers, for git-cherry to make it more
> precise (to detect duplicated/cherry-picked changes better), and in
> the future possibly to help history-aware merge strategies. And probably
> help patch management interfaces.
Can I suggest,
1. bury this origin link idea
2. make git-cherry-pick have a similar option to '-x', but instead of
recording the original commit ID, record the original *patch* ID,
*if* there was a merge conflict for that cherry pick.
3. tools can build indexes from patch ID => (commit IDs) to make this
other form of history navigation fast.
Sam
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-11 23:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809111533110.3384@nehalem.linux-foundation.org>
On Thu, Sep 11, 2008 at 04:10:26PM -0700, Linus Torvalds wrote:
> > And obviously in Linus's workflow such references are basically useless,
> > and they should just not be generated.
>
> This has _nothing_ to do with workflows or anything else.
>
> Why are people claiming these total red herrings?
>
> I have asked several times what it is that makes it so important that the
> "origin" information be in the headers. Nobody has been able to explain
> why it's so different from just doing it in the free-form part. NOBODY.
The message you are responding to has nothing to do with an origin
header versus putting it in the free-form part. It is equally a problem
with both approaches.
I was purely commenting on the "if I mention an arbitrary sha-1, what is
the person reading it supposed to _do_ with it, if they may never have
seen that sha-1" issue.
So yes, it has _everything_ to do with workflows. In Stephen's case, he
claims that all references will be to commits on long-lived branches. In
which case, it is a non-issue because they will have the referenced
commits.
But in the general case, people will not have them, and there is
potential head-scratching. My point is that even if a feature works for
Stephen's workflow, it may not be a good feature for everyone, since
other solutions handle the general case (as well as his case) much
better.
> [ranting about how the origin header is bad]
> The only thing I have ever argued against is adding commit headers that
> have no sane semantics and don't make sense as internal git data
> structures.
Yes, and I totally agree with everything you said. If you read the mail
you are responding to carefully, you will see that I never mention an
origin header versus the free-form commit.
-Peff
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 23:17 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911230117.GA4194@coredump.intra.peff.net>
Jeff King wrote:
>On Fri, Sep 12, 2008 at 12:56:48AM +0200, Stephen R. van den Berg wrote:
>> Well, the usual way to fix this is to actually startup fetch and tell it
>> to try and fetch all the weak links (or just fetch a single hash (the
>> offending origin link)) from upstream; this is by no means the default
>> operatingmode of fetch, but I don't see any harm in allowing to fetch
>> those if one really wants to.
>Maybe I am misremembering the details of fetching, but I believe you
>cannot fetch an arbitrary SHA-1, and that is by design. So:
I see, didn't know that.
> 1. You would have to argue the merits of changing that design. I
> believe the rationale relates to exposing some subset of the
> content via refs, but I have personally never felt that is very
> compelling.
Well, I can understand why it is done this way, I think.
> 2. Even if we did make a change, that means that _both_ sides need the
> upgraded version.
If you're using origin links, you'd need that anyway, so that's a given.
I could imagine the minimum would be something like:
Allow direct SHA1 fetches (which obviously pull in all parents as well)
if the ref is part of one of the public branches (either as a commit,
or as an origin link).
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-11 23:10 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Stephen R. van den Berg, Jakub Narebski, git
In-Reply-To: <20080911214650.GB3187@coredump.intra.peff.net>
On Thu, 11 Sep 2008, Jeff King wrote:
>
> And obviously in Linus's workflow such references are basically useless,
> and they should just not be generated.
This has _nothing_ to do with workflows or anything else.
Why are people claiming these total red herrings?
I have asked several times what it is that makes it so important that the
"origin" information be in the headers. Nobody has been able to explain
why it's so different from just doing it in the free-form part. NOBODY.
If somebody has a workflow where they want to track "origin" commits, then
they can do it today with the in-body approach. But that has nothing
what-so-ever to do with the question of "let's change object file format
to some odd special-case that we just made up and is only apparently
useful for some special workflow that uses special tools and special
rules".
I want the git object database to have really clear semantics. The fields
we have now, we have because we _require_ them. There is nothing unclear
what-so-ever about the semantics of author/commiter-ship, parenthood,
trees, or anything else.
And there are _zero_ issues about "workflow". The workflow doesn't matter,
the objects always make sense, and they always work exactly the same way.
There are no special magic cases that are in the least questionable in any
way.
So this argument is about more than just "minimalism", although I'll also
admit to that being an issue - I want to be able to basically explain how
git data structures work to any CS student, and not have any extra fat or
any gray areas. It's about everything having a clear design, and a clear
meaning, and there never being any question what-so-ever about what the
real "meaning" of something is.
Then, if you have some special use case or rules for your particular
project, well that's where you can have things like formatting rules for
how the commit messages should look like. If somebody wants to use fixed
format rules for their project, that's fine. And THAT is where "workflow"
issues come up.
But "workflow" has nothing to do with core git data structures. They were
designed for speed, stability, simplicity and good taste. The _workflow_
part has been designed on separately on top of that (example: the whole
thing with a single-line top summary of a commit so that we can have "git
shortlog" and the "gitk" single-line commit view etc).
Of course, good and generally useful workflows can then be reflected in
how tools work, where that single line commit summary is an example of
that: it's not something that git data structures _enforce_ or even care
about, but it's obviously something that a lot of the porcelain expects,
and without it, lots of tools will output less useful information.
The same goes for the existing SHA1-in-comment support: some tools already
support it and help view it in certain ways, even though it is in no way a
core data structure issue. And _extending_ on that kind of helpful
porcelain support certainly makes sense.
The only thing I have ever argued against is adding commit headers that
have no sane semantics and don't make sense as internal git data
structures.
Linus
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Jeff Whiteside @ 2008-09-11 23:04 UTC (permalink / raw)
To: Eric Raible; +Cc: Junio C Hamano, git
In-Reply-To: <279b37b20809111519o76bea81br738983b4cda1978e@mail.gmail.com>
The command is wrapped up in all kinds of semantics at which you have
to guess or read tons of vague or outdated literature. That's what
makes git's learning curve so retarded.
Why is it not just git reset --index or git reset
--worktree or git reset --commitrepo REVISION or git reset
--all ?
And if you want to delete all untracked files
ls | sed s/`git status --index --filenamesonly`//g | rm
ls | sed s/`git status --commitrepo --filenamesonly`//g | rm
(I realize those commands don't actually work, but I'm a noob.)
So that 'tracked by git' isn't just another ambiguous semantic.
Instead 'Tracked by index'/'Tracked by commitrepo'.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-11 23:01 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911225648.GC29559@cuci.nl>
On Fri, Sep 12, 2008 at 12:56:48AM +0200, Stephen R. van den Berg wrote:
> Well, the usual way to fix this is to actually startup fetch and tell it
> to try and fetch all the weak links (or just fetch a single hash (the
> offending origin link)) from upstream; this is by no means the default
> operatingmode of fetch, but I don't see any harm in allowing to fetch
> those if one really wants to.
Maybe I am misremembering the details of fetching, but I believe you
cannot fetch an arbitrary SHA-1, and that is by design. So:
1. You would have to argue the merits of changing that design. I
believe the rationale relates to exposing some subset of the
content via refs, but I have personally never felt that is very
compelling.
2. Even if we did make a change, that means that _both_ sides need the
upgraded version.
-Peff
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 22:56 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911214650.GB3187@coredump.intra.peff.net>
Jeff King wrote:
>On Thu, Sep 11, 2008 at 04:04:53PM -0400, Theodore Tso wrote:
>> > It will be q^..q, and specifically not p^..p, using ^p..p would be
>> > lying. We aim to document the evolvement of the patch in time.
>> > Cherry-pick itself will always ignore the origin links present on the
>> > old commit, it simply creates new ones as if the old ones didn't exist.
>> So if you never pull branch C (where commit q resides), there is no
>> way for you to know that commits p and r are related. How.... not
>> useful.
>But what about workflows in between? When I pull from some developer who
>has added a weak reference to a particular commit SHA1, but I _don't_
>have that commit, my next question "OK, so what was in that commit?".
>What is the mechanism by which I find out more information on that SHA1?
Well, the usual way to fix this is to actually startup fetch and tell it
to try and fetch all the weak links (or just fetch a single hash (the
offending origin link)) from upstream; this is by no means the default
operatingmode of fetch, but I don't see any harm in allowing to fetch
those if one really wants to.
>Using a key that is meaningful to an external database (like a bug
>tracker) means that you can go to that database to look up more
>information.
True. And also a Good Thing, I concur.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ 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