Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
Sebastian Schuberth sschube...@gmail.com writes: On Thu, Jul 23, 2015 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote: I haven't dug into why that happens, but possible ways to fix that are to make --quiet output all (making it consistent with -s) or no (making the command totally silent) output at all ;-). Exactly, and I chose the latter to add some value to --quiet instead of making it an alias for -s. Heh. You didn't even know when diff-tree --stdin --quiet would be useful, let alone that it had a bug that made it useless for that exact use case. So it cannot be I chose the latter. I just gave you a hint so that you can write a plausible-sounding justification, and we both know that it is very different from your original motivation. Be honest. Perhaps the log message would say something like this: $ git rev-list ... | git diff-tree --stdin --quiet [$pathspec] is a way to list the commits that modifies the named paths, but this bug analysis of the bug comes here makes it not to emit all such commits. It couldn't have been used by existing scripts with this longstanding bug. We could fix it so that it does not randomly skip commits that ought to be shown, but that feature is already available by the -s option instead of --quiet. So let's change the meaning of --quiet to make it really quiet, without giving any output. Strictly speaking, this may break backward compatibility but the existing behaviour to randomly omit commits couldn't have been useful, so there is no harm done. And as an added bonus, $ git diff-tree --quiet $commit [$pathspec] would stop showing the commit object name. The analysis of the bug is really crucial for the above description to work as justification for this change, substanciating the words longstanding and randomly omit that are used to convince us that this option couldn't have been used by real scripts. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
On Thu, Jul 23, 2015 at 7:06 PM, Junio C Hamano gits...@pobox.com wrote: Existing scripts by definition would not be using a new option you will invent that used not to be a valid one. So that would be one way that you can shorten your script without breaking other people. True. If it was only for shortening my script, I still could do /dev/null 21 which is just as short (or long) as a newly introduced --really-quiet option. But I'm also concerned about consistency and making options do what they sound they would do. In git rev-list ... | git diff-tree --stdin output, the commit object name is absolutely necessary, with or without --quiet, as it Why is printing the object name also necessary with --quiet? I'd argue that any script that uses diff-tree that way uses --stdin without --quiet, just like you do in your example, so suppressing the object name if --quiet is given probably would not break as many scripts as you think. But we do not live in an ideal world. True, but we should never stop striving after making it one :-) -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] log: add log.firstparent option
On Wed, Jul 22, 2015 at 6:23 PM, Jeff King p...@peff.net wrote: This patch adds an option to turn on --first-parent all the time, along with the corresponding --no-first-parent to disable it. The why of this requires a bit of backstory. Some projects (like git.git) encourage frequent rebasing to generate a set of clean, bisectable patches for each topic. The messy sequence of bug-ridden and bug-fixup commits is lost in the rebase, and not part of the final history. But other projects prefer to keep the messy history intact. For one thing, it makes collaboration on a topic easier, as developers can simply pull from each other during the messy development. And two, that history may later be useful when tracking down a bug, because it gives more insight into the actual thought process of the developer. But in this latter case you want _two_ views of history. You may want to see the simple version in which a series of fully-formed topics hit the branch (and you would like to see the diff of their final form). Or you may want to see the messy details, because you are digging into a bug related to the topic. One proposal we have seen in the past is to keep the messy history as a shadow parent of the real commits. That is, to introduce a new parent-like header into the commit object, but not traverse it by default in git log. So it remains hidden until you ask to dig into a particular topic (presumably with a log --show-messy-parents option or similar). So by default you get the simple view, but can dig further if you wish. But we can observe that such shadow parents can be implemented as real parents; the problem isn't one of the underlying data structure, but how we present it in git log. In other words, a perfectly reasonable workflow is: - make your messy commits on a side branch - do a non-fast-forward merge to bring them into master. The commit message for this merge should be meaningful and describe the topic as a whole. - view the simple history with git log --first-parent -m - view the complex history with git log But since you probably want to view the simple history most of the time, it would be nice to be able to default to that, and switch to the more complicated view with a command line option. Hence this patch. Suggested-by: Josh Bleecher Snyder joshar...@gmail.com --- This came out of a discussion I had with Josh as OSCON. I don't think I would personally use it, because git.git is not a messy-workflow project. But I think that GitHub pushes people into this sort of workflow (the PR becomes the interesting unit of change), and my understanding is that Gerrit does, as well. Github pull request messages are similar to cover letters, so you could send a series with a good cover letter, but crappy unfinished patches inside the series. After applying all patches it could be all nice, i.e. compiles, tests, adds the new functionality. It might be just a commit in between which may not even compile. That's my understanding of the messy-workflow. Gerrit cannot provide such a workflow easily as it's rather commit centric and not branch centered. So you need to approve each commit on its own and until 2 weeks ago you even needed to submit each commit. (By now Gerrit has learned to submit a full branch, that is you submit a commit and all its ancestors will integrate as well if they were approved.) Previously when the ancestors were not approved the commit would be submitted, merge pending, so it would wait for each commit to be approved and submitted. And because of this commit-centric workflow, the crappy commit in the series is put into spot light. Apart from that, the first-parent option gains some traction currently, Compare https://git.eclipse.org/r/#/c/52381/ for example ;) There are probably some other things we (and others) could do to help support it: - currently --first-parent -p needs -m to show anything useful; this is being discussed elsewhere, and it would be nice if it Just Worked (and showed the diff between the merge and the first-parent) - the commit messages for merges are often not great. A few versions ago, I think, we started opening the editor for merges, which is good. GitHub's PR-merge includes the PR subject in the commit message, but not all of the rationale and discussion. And in both git-generated and GitHub-generated messages, the subject isn't amazing (it's merge topic jk/some-shorthand, which is barely tolerable if you use good branch names; it could be something like the subject-line of the cover letter for the patch series). So I think this could easily be improved by GitHub (we have the PR subject and body, after all). It's harder for a mailing list project like git.git, because Git never actually sees the subject line. I think it would require teaching git-am the concept of a patch series. This
Re: [RFC/PATCH] log: add log.firstparent option
Jeff King p...@peff.net writes: But other projects prefer to keep the messy history intact. For one thing, it makes collaboration on a topic easier, as developers can simply pull from each other during the messy development. And two, that history may later be useful when tracking down a bug, because it gives more insight into the actual thought process of the developer. But in this latter case you want _two_ views of history. You may want to see the simple version in which a series of fully-formed topics hit the branch (and you would like to see the diff of their final form). Or you may want to see the messy details, because you are digging into a bug related to the topic. While I can see the reasoning behind the above [*1*], I am not sure if the output with --first-parent would always be a good match for the simple version. Wouldn't the people who keep these messy histories also those who merge project trunk into a random topic and push the result back as the updated project trunk? Admittedly, that merely is saying that --first-parent is not a solution to such a project, and does not say much about the usefulness of the new configuration, so I'd queue it as-is. [Footnote] *1* I do not necessarily agree, though. The history being messy is a sign that the actual thought process of the developer was not clearly expressed in the work, and it is not likely that you have more insight by looking at it---you will see more mess, for certain, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
On Thu, Jul 23, 2015 at 9:39 PM, Junio C Hamano gits...@pobox.com wrote: I haven't dug into why that happens, but possible ways to fix that are to make --quiet output all (making it consistent with -s) or no (making the command totally silent) output at all ;-). Exactly, and I chose the latter to add some value to --quiet instead of making it an alias for -s. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] mh: worktree-related doc fixes
On Mon, Jul 20, 2015 at 11:31 AM, Michael Haggerty mhag...@alum.mit.edu wrote: On 07/19/2015 10:29 PM, Eric Sunshine wrote: This re-roll of Michael Haggerty's worktree-related documentation tweaks[1] takes my review comments into account and adds one new patch. Thanks for separating the wheat from the chaff. I'm still traveling, which I'll claim as an excuse for my poor responsiveness. All of your changes look good. I was wondering one thing: is there a value like never or false to which gc.worktreepruneexpire can be set to turn off pruning entirely? If so, it might be nice to mention it in the config manpage. Similarly for the other expiration grace time settings. But it's definitely not a blocker. I browsed the code for the various expire settings, and it appears that they all accept and respect now and never, as well, so I'll put together a patch as suggested. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
Eric Sunshine sunsh...@sunshineco.com writes:
On Wed, Jul 22, 2015 at 5:05 PM, Jacob Keller jacob.e.kel...@intel.com
wrote:
From: Jacob Keller jacob.kel...@gmail.com
Modify logic of check_refname_component and add a new disposition
regarding *. Allow refspecs that contain a single * if
REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as
a pointer, and clear REFNAME_REFSPEC_PATTERN after the first * so that
only a single * is accepted.
This loosens restrictions on refspecs by allowing patterns that have
a * within a component instead of only as the whole component. Also
remove the code that hangled refspec patterns in check_refname_format
s/hangled/handled/
...
Thanks; here is what I queued yesterday.
-- 8 --
From: Jacob Keller jacob.kel...@gmail.com
Date: Wed, 22 Jul 2015 14:05:33 -0700
Subject: [PATCH] refs: loosen restriction on wildcard * refspecs
Loosen restrictions on refspecs by allowing patterns that have a *
within a component instead of only as the whole component.
Remove the logic to accept a single * as a whole component from
check_refname_format(), and implement an extended form of that logic
in check_refname_component(). Pass the pointer to the flags argument
to the latter, as it has to clear REFNAME_REFSPEC_PATTERN bit when
it sees *.
Teach check_refname_component() function to allow an asterisk *
only when REFNAME_REFSPEC_PATTERN is set in the flags, and drop the
bit after seeing a *, to ensure that one side of a refspec
contains at most one asterisk.
This will allow us to accept refspecs such as `for/bar*:foo/baz*`.
Any refspec which functioned before shall continue functioning with
the new logic.
Signed-off-by: Jacob Keller jacob.kel...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-check-ref-format.txt | 4 ++--
refs.c | 36 +++---
refs.h | 4 ++--
t/t1402-check-ref-format.sh| 8 +---
t/t5511-refspec.sh | 11 +++
5 files changed, 36 insertions(+), 27 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index fc02959..9044dfa 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -94,8 +94,8 @@ OPTIONS
Interpret refname as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, refname is allowed to contain a single `*`
- in place of a one full pathname component (e.g.,
- `foo/*/bar` but not `foo/bar*`).
+ in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
+ but not `foo/bar*/baz*`).
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
diff --git a/refs.c b/refs.c
index 0900f54..3127518 100644
--- a/refs.c
+++ b/refs.c
@@ -21,12 +21,13 @@ struct ref_lock {
* 2: ., look for a preceding . to reject .. in refs
* 3: {, look for a preceding @ to reject @{ in refs
* 4: A bad character: ASCII control characters, and
- **, :, ?, [, \, ^, ~, SP, or TAB
+ *:, ?, [, \, ^, ~, SP, or TAB
+ * 5: *, reject unless REFNAME_REFSPEC_PATTERN is set
*/
static unsigned char refname_disposition[256] = {
1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
- 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 2, 1,
+ 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,
@@ -73,12 +74,13 @@ static unsigned char refname_disposition[256] = {
* - any path component of it begins with ., or
* - it has double dots .., or
* - it has ASCII control characters, or
- * - it has *, :, ?, [, \, ^, ~, SP, or TAB anywhere, or
+ * - it has :, ?, [, \, ^, ~, SP, or TAB anywhere, or
+ * - it has * anywhere unless REFNAME_REFSPEC_PATTERN is set, or
* - it ends with a /, or
* - it ends with .lock, or
* - it contains a @{ portion
*/
-static int check_refname_component(const char *refname, int flags)
+static int check_refname_component(const char *refname, int *flags)
{
const char *cp;
char last = '\0';
@@ -99,6 +101,16 @@ static int check_refname_component(const char *refname, int
flags)
break;
case 4:
return -1;
+ case 5:
+ if (!(*flags REFNAME_REFSPEC_PATTERN))
+ return -1; /* refspec can't be a pattern */
+
+ /*
+* Unset the pattern flag so that we only accept
+* a single asterisk for one side of refspec.
+*/
+ *flags = ~ REFNAME_REFSPEC_PATTERN;
+ break;
How to organize multiple small reusable components with Git?
I am using git to manage some circuit components. Each component is small and I plan to create a component project in Git to hold all the small components. Each component may have several released version, such as Comonent1_V1, Component1_V2, Comonent2_V1, Component2_V2. And for future reuse, I may use Component1_V1+Component2_V2, or Component1_V2+Component2_V1 in my local directory. So, I plan to create several directories, each for one version of one component. I looks like followings: Components |--Component1 | |--Version1(Dir) | |--Version2(Dir) |---Component2 |--Version1(Dir) |--Version2(Dir) I want to know, is the above a suitable way in Git? Are there some risks for my project and Git? Any suggestions to cover this case in Git? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git branch -v output ambiguous for parser
On do, 2015-07-23 at 15:29 +0200, Thibault Kruse wrote: Hi, trying to write a git wrapper, I wanted to parse the output of git branch -v The output of git branch is not meant to be machine-parsed. Try using git for-each-ref :) -- Dennis Kaarsemaker http://www.kaarsemaker.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to organize multiple small reusable components with Git?
Hi Bing, You seem to be describing a very interesting problem, similar to what I often run into in my day job. In my day job I'm composing multiple java microservices into a single application. We have about 7 microservices, but this number will probably grow to more than 10 before the application is feature-complete. Because microservices are mutually independent and unaware of each other (however, they _do_ share knowledge of message formats exchanged on the message queue), we have a very acute problem of composing entire system together. The problem is two-fold: 1) how do you know which set of the versions of components gives you a working system? 2) how do you keep track of a record of [the sets of the versions of components] which give you a working system? Part 1) is much more difficult than part 2). Although part 1) lies outside of the scope of version control I'd like to pay your attention to it nonetheless. In principle with 10 versions of 10 components you have 10 billion possibly valid configurations of the system. In such circumstance it is very helpful to use such good SE practices like depcrecation warnings, semantic versioning and clean distinction between interface and its implementation. You can also do it the linux kernel way by simply never introducing backwards-incompatible changes. If you want to read up about semantic versioning, here's the link to the standard: http://semver.org/ Part 2) is really what git can help you with: One way to deal with this is to manage each component in a separate git repository (thus version each component separately) and have a thin parent project, which imports all other projects as submodules. The way submodules work is through storing each submodule as a separate directory. You can go to each of the submodule directories, checkout a particular commit which you want to be marked as a part of your system and mark each component with usual command git add submodule_dir. That obviously assumes that you've already solved Part 1) and you know what versions of components give you a working system. You can repeat this process for each submodule and once you're happy commit the result in the parent project and push to the remote. You can also do usual git things such as tags for example. I'm not sure how much I like this solution though: having multiple repositories seems to be an overkill for most cases. Behaviour of submodules has been startling on a few occasions (for example `git submodule update` can actually take you back in time rather than forward). I've also experienced several peculiar and difficult to pinpoint issues on windows. Although I haven't used it much, git subtrees seems to be much nicer alternative. You can read about them here: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ As to your original idea about having multiple separate directories, I'm not sure I like it at all. By splitting the versions of your components into separate directories you loose a lot of benefits of version control. With multiple directories you won't be able to apply hotfixes to multiple versions of the component for example without rewriting the logic of cherry-pick. Cheers, Adam On 23 July 2015 at 12:20, Bing Tian tianbing1...@gmail.com wrote: I am using git to manage some circuit components. Each component is small and I plan to create a component project in Git to hold all the small components. Each component may have several released version, such as Comonent1_V1, Component1_V2, Comonent2_V1, Component2_V2. And for future reuse, I may use Component1_V1+Component2_V2, or Component1_V2+Component2_V1 in my local directory. So, I plan to create several directories, each for one version of one component. I looks like followings: Components |--Component1 | |--Version1(Dir) | |--Version2(Dir) |---Component2 |--Version1(Dir) |--Version2(Dir) I want to know, is the above a suitable way in Git? Are there some risks for my project and Git? Any suggestions to cover this case in Git? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git branch -v output ambiguous for parser
Hi, trying to write a git wrapper, I wanted to parse the output of git branch -v However, I realized that the output prints the last commit message at the end of the line, without any disambigution char, or hyphens. This makes it possible to have these outputs: foo 6d29736 [foo/bar] test123 master 9726de6 [ahead 2, behind 2] line 1 line 2 line 3 where foo is a branch that does not track another branch, and the last commit message on branch foo is '[foo/bar] test123'. The opening brackets '[' are even aligned in the output, making that distinction also difficult for the human eye. So as a small improvement I would suggest some separating char or hyphens around the commit message, e.g.: foo 6d29736 '[foo/bar] test123' foo 6d29736 | [foo/bar] test123 regards, Thibault Kruse -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git hooks and environment variables
I've noticed that not all hooks have all of the environment variables set when they are run, and it is not clear from the manual pages which hooks have which variables set on the command line. Specifically, they don't all have GIT_DIR set, I haven't taken the time to verify exactly which variables are set and which are not yet, but.. Which would be preferred? documentation of the current behaviors, or a fixup that ensures that all the relevant variables get set? I intend to have complete details as to which hooks get one settings, but I had this at work and don't have it here, so I can update this thread with the information later. Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
On Thu, 2015-07-23 at 15:12 -0700, Junio C Hamano wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Wed, Jul 22, 2015 at 5:05 PM, Jacob Keller
jacob.e.kel...@intel.com wrote:
From: Jacob Keller jacob.kel...@gmail.com
Modify logic of check_refname_component and add a new disposition
regarding *. Allow refspecs that contain a single * if
REFNAME_REFSPEC_PATTERN is set. Change the function to pass the
flags as
a pointer, and clear REFNAME_REFSPEC_PATTERN after the first *
so that
only a single * is accepted.
This loosens restrictions on refspecs by allowing patterns that
have
a * within a component instead of only as the whole component.
Also
remove the code that hangled refspec patterns in
check_refname_format
s/hangled/handled/
...
Thanks; here is what I queued yesterday.
Woah. I bow to your imperative commit message abilities. The new commit
message is very nicely worded. Thanks for taking the time to reword my
jumble correctly.
Everything looked great to me.
Regards,
JakeN�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
[PATCH/RFC 0/9] Pseudorefs
This series is another chunk of the pluggable refs backend work. The major reason it is listed as PATCH/RFC is beacuse it breaks t9300-fast-import.sh, because fast-import wants to create a ref called TEMP_TAG, which would now be a pseudoref. The commit that introduces this test says that cvs2svn creates a tag called TAG_FIXUP as a branch name for temporary work needed to cleanup the tree prior to creating an annotated tag object. It appears that cvs2svn still does this. So I'm not quite sure what to do about this particular case. As we discussed earlier, the motivation for this series is that refs backends other than the files-based backend need to treat per-worktree refs (HEAD) and pseudorefs (FETCH_HEAD) differently from other refs; other refs are per-repo rather than per-worktree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
Keller, Jacob E jacob.e.kel...@intel.com writes: s/hangled/handled/ ... Thanks; here is what I queued yesterday. Woah. I bow to your imperative commit message abilities. The new commit message is very nicely worded. Heh, imperative is secondary. I just wanted to straighten out the use of refs and refspecs there. Thanks for a patch that was cleanly done. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] mh: worktree-related doc fixes
Eric Sunshine sunsh...@sunshineco.com writes: On Mon, Jul 20, 2015 at 11:31 AM, Michael Haggerty mhag...@alum.mit.edu wrote: On 07/19/2015 10:29 PM, Eric Sunshine wrote: This re-roll of Michael Haggerty's worktree-related documentation tweaks[1] takes my review comments into account and adds one new patch. Thanks for separating the wheat from the chaff. I'm still traveling, which I'll claim as an excuse for my poor responsiveness. All of your changes look good. I was wondering one thing: is there a value like never or false to which gc.worktreepruneexpire can be set to turn off pruning entirely? If so, it might be nice to mention it in the config manpage. Similarly for the other expiration grace time settings. But it's definitely not a blocker. I browsed the code for the various expire settings, and it appears that they all accept and respect now and never, as well, so I'll put together a patch as suggested. Sounds good; thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] notes: replace pseudorefs with real refs
All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are per-worktree. We don't want multiple notes merges happening at once (in different worktrees), so we want to make these refs true refs. So, we lowercase NOTES_MERGE_REF and friends. That way, backends that distinguish between pseudorefs and real refs can correctly handle notes merges. This will also enable us to prevent pseudorefs from being updated by the ref update machinery e.g. git update-ref. Signed-off-by: David Turner dtur...@twopensource.com --- Documentation/git-notes.txt | 12 ++--- builtin/notes.c | 38 notes-merge.c | 10 ++-- notes-merge.h | 8 ++-- t/t3310-notes-merge-manual-resolve.sh | 86 +-- t/t3311-notes-merge-fanout.sh | 6 +-- 6 files changed, 80 insertions(+), 80 deletions(-) diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 851518d..82fa3fd 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -103,7 +103,7 @@ merge:: If conflicts arise and a strategy for automatically resolving conflicting notes (see the -s/--strategy option) is not given, the manual resolver is used. This resolver checks out the -conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), +conflicting notes in a special worktree (`.git/notes_merge_worktree`), and instructs the user to manually resolve the conflicts there. When done, the user can either finalize the merge with 'git notes merge --commit', or abort the merge with @@ -189,11 +189,11 @@ OPTIONS --commit:: Finalize an in-progress 'git notes merge'. Use this option when you have resolved the conflicts that 'git notes merge' - stored in .git/NOTES_MERGE_WORKTREE. This amends the partial + stored in .git/notes_merge_worktree. This amends the partial merge commit created by 'git notes merge' (stored in - .git/NOTES_MERGE_PARTIAL) by adding the notes in - .git/NOTES_MERGE_WORKTREE. The notes ref stored in the - .git/NOTES_MERGE_REF symref is updated to the resulting commit. + .git/notes_merge_partial) by adding the notes in + .git/notes_merge_worktree. The notes ref stored in the + .git/notes_merge_ref symref is updated to the resulting commit. --abort:: Abort/reset a in-progress 'git notes merge', i.e. a notes merge @@ -241,7 +241,7 @@ NOTES MERGE STRATEGIES The default notes merge strategy is manual, which checks out conflicting notes in a special work tree for resolving notes conflicts -(`.git/NOTES_MERGE_WORKTREE`), and instructs the user to resolve the +(`.git/notes_merge_worktree`), and instructs the user to resolve the conflicts in that work tree. When done, the user can either finalize the merge with 'git notes merge --commit', or abort the merge with diff --git a/builtin/notes.c b/builtin/notes.c index 63f95fc..e0b8a02 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -670,14 +670,14 @@ static int merge_abort(struct notes_merge_options *o) int ret = 0; /* -* Remove .git/NOTES_MERGE_PARTIAL and .git/NOTES_MERGE_REF, and call -* notes_merge_abort() to remove .git/NOTES_MERGE_WORKTREE. +* Remove .git/notes_merge_partial and .git/notes_merge_ref, and call +* notes_merge_abort() to remove .git/notes_merge_worktree. */ - if (delete_ref(NOTES_MERGE_PARTIAL, NULL, 0)) - ret += error(Failed to delete ref NOTES_MERGE_PARTIAL); - if (delete_ref(NOTES_MERGE_REF, NULL, REF_NODEREF)) - ret += error(Failed to delete ref NOTES_MERGE_REF); + if (delete_ref(notes_merge_partial, NULL, 0)) + ret += error(Failed to delete ref notes_merge_partial); + if (delete_ref(notes_merge_ref, NULL, REF_NODEREF)) + ret += error(Failed to delete ref notes_merge_ref); if (notes_merge_abort(o)) ret += error(Failed to remove 'git notes merge' worktree); return ret; @@ -694,16 +694,16 @@ static int merge_commit(struct notes_merge_options *o) int ret; /* -* Read partial merge result from .git/NOTES_MERGE_PARTIAL, -* and target notes ref from .git/NOTES_MERGE_REF. +* Read partial merge result from .git/notes_merge_partial, +* and target notes ref from .git/notes_merge_ref. */ - if (get_sha1(NOTES_MERGE_PARTIAL, sha1)) - die(Failed to read ref NOTES_MERGE_PARTIAL); + if (get_sha1(notes_merge_partial, sha1)) + die(Failed to read ref notes_merge_partial); else if (!(partial = lookup_commit_reference(sha1))) - die(Could not find commit from NOTES_MERGE_PARTIAL.); + die(Could not find commit from notes_merge_partial.); else if (parse_commit(partial)) - die(Could not parse commit from
[PATCH 4/9] tests: treat FETCH_HEAD as a pseudoref
Signed-off-by: David Turner dtur...@twopensource.com
---
t/t5510-fetch.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 0ba9db0..467cade 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -362,7 +362,7 @@ test_expect_success 'fetch with a non-applying
branch.name.merge' '
test_expect_success 'fetch from GIT URL with a non-applying
branch.name.merge [1]' '
one_head=$(cd one git rev-parse HEAD)
this_head=$(git rev-parse HEAD)
- git update-ref -d FETCH_HEAD
+ rm .git/FETCH_HEAD
git fetch one
test $one_head = $(git rev-parse --verify FETCH_HEAD)
test $this_head = $(git rev-parse --verify HEAD)
@@ -374,7 +374,7 @@ test_expect_success 'fetch from GIT URL with a non-applying
branch.name.merge
one_ref=$(cd one git symbolic-ref HEAD)
git config branch.master.remote blub
git config branch.master.merge $one_ref
- git update-ref -d FETCH_HEAD
+ rm .git/FETCH_HEAD
git fetch one
test $one_head = $(git rev-parse --verify FETCH_HEAD)
test $this_head = $(git rev-parse --verify HEAD)
@@ -384,7 +384,7 @@ test_expect_success 'fetch from GIT URL with a non-applying
branch.name.merge
# the merge spec does not match the branch the remote HEAD points to
test_expect_success 'fetch from GIT URL with a non-applying
branch.name.merge [3]' '
git config branch.master.merge ${one_ref}_not
- git update-ref -d FETCH_HEAD
+ rm .git/FETCH_HEAD
git fetch one
test $one_head = $(git rev-parse --verify FETCH_HEAD)
test $this_head = $(git rev-parse --verify HEAD)
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] bisect: do not use update-ref for BISECT_HEAD
Because BISECT_HEAD is a pseudoref, we shouldn't use update-ref to
update it. Instead, we simply write to and delete the file.
Signed-off-by: David Turner dtur...@twopensource.com
---
git-bisect.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index ea63223..8263555 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -181,7 +181,7 @@ bisect_start() {
#
echo $start_head $GIT_DIR/BISECT_START {
test z$mode != z--no-checkout ||
- git update-ref --no-deref BISECT_HEAD $start_head
+ git rev-parse $start_head $GIT_DIR/BISECT_HEAD
}
git rev-parse --sq-quote $@ $GIT_DIR/BISECT_NAMES
eval $eval true
@@ -425,7 +425,7 @@ bisect_clean_state() {
rm -f $GIT_DIR/BISECT_TERMS
# Cleanup head-name if it got left by an old version of git-bisect
rm -f $GIT_DIR/head-name
- git update-ref -d --no-deref BISECT_HEAD
+ rm -f $GIT_DIR/BISECT_HEAD
# clean up BISECT_START last
rm -f $GIT_DIR/BISECT_START
}
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] pseudorefs: create and use pseudoref update and delete functions
Pseudorefs should not be updated through the ref API, because the ref
API is for real refs. Instead, use a dedicated pseudoref API.
This patch changes writes to CHERRY_PICK_HEAD, REVERT_HEAD, and ORIG_HEAD.
Signed-off-by: David Turner dtur...@twopensource.com
---
builtin/merge.c | 3 +--
builtin/reset.c | 6 ++
refs.c | 55 ++-
refs.h | 5 +
sequencer.c | 21 ++---
5 files changed, 64 insertions(+), 26 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 7e2541a..cea57a0 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1354,8 +1354,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
free(list);
}
- update_ref(updating ORIG_HEAD, ORIG_HEAD, head_commit-object.sha1,
- NULL, 0, UPDATE_REFS_DIE_ON_ERR);
+ write_pseudoref(ORIG_HEAD, head_commit-object.sha1, NULL);
if (remoteheads !common)
; /* No common ancestors found. We need a real merge. */
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..0282e78 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -252,11 +252,9 @@ static int reset_refs(const char *rev, const unsigned char
*sha1)
old_orig = sha1_old_orig;
if (!get_sha1(HEAD, sha1_orig)) {
orig = sha1_orig;
- set_reflog_message(msg, updating ORIG_HEAD, NULL);
- update_ref(msg.buf, ORIG_HEAD, orig, old_orig, 0,
- UPDATE_REFS_MSG_ON_ERR);
+ write_pseudoref(ORIG_HEAD, orig, old_orig);
} else if (old_orig)
- delete_ref(ORIG_HEAD, old_orig, 0);
+ delete_pseudoref(ORIG_HEAD, old_orig);
set_reflog_message(msg, updating HEAD, rev);
update_ref_status = update_ref(msg.buf, HEAD, sha1, orig, 0,
UPDATE_REFS_MSG_ON_ERR);
diff --git a/refs.c b/refs.c
index d31ca42..efa84e3 100644
--- a/refs.c
+++ b/refs.c
@@ -3862,7 +3862,7 @@ int is_per_worktree_ref(const char *refname)
return !strcmp(refname, HEAD);
}
-static int is_pseudoref(const char *refname)
+int is_pseudoref(const char *refname)
{
const char *c;
@@ -4544,3 +4544,56 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
unlock_ref(lock);
return -1;
}
+
+void write_pseudoref(const char *pseudoref, const unsigned char *sha1,
+const unsigned char *old_sha1)
+{
+ const char *filename;
+ int fd;
+ static struct lock_file lock;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(buf, %s\n, sha1_to_hex(sha1));
+
+ filename = git_path(%s, pseudoref);
+ fd = hold_lock_file_for_update(lock, filename, LOCK_DIE_ON_ERROR);
+ if (fd 0)
+ die_errno(_(Could not open '%s' for writing), filename);
+
+ if (old_sha1) {
+ unsigned char actual_old_sha1[20];
+ read_ref(pseudoref, actual_old_sha1);
+ if (hashcmp(actual_old_sha1, old_sha1))
+ die(Unexpected sha1 when writing %s, pseudoref);
+ }
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len)
+ die_errno(_(Could not write to '%s'), filename);
+ strbuf_release(buf);
+ commit_lock_file(lock);
+}
+
+void delete_pseudoref(const char *pseudoref, const unsigned char *old_sha1)
+{
+ static struct lock_file lock;
+ const char *filename;
+
+ filename = git_path(%s, pseudoref);
+
+ if (old_sha1) {
+ int fd;
+ unsigned char actual_old_sha1[20];
+
+ fd = hold_lock_file_for_update(lock, filename,
+ LOCK_DIE_ON_ERROR);
+ if (fd 0)
+ die_errno(_(Could not open '%s' for writing),
filename);
+ read_ref(pseudoref, actual_old_sha1);
+ if (hashcmp(actual_old_sha1, old_sha1))
+ die(Unexpected sha1 when writing %s, pseudoref);
+
+ unlink(pseudoref);
+ rollback_lock_file(lock);
+ } else {
+ unlink(pseudoref);
+ }
+}
diff --git a/refs.h b/refs.h
index bd5526e..450860b 100644
--- a/refs.h
+++ b/refs.h
@@ -441,6 +441,11 @@ int update_ref(const char *msg, const char *refname,
const unsigned char *new_sha1, const unsigned char *old_sha1,
unsigned int flags, enum action_on_err onerr);
+void write_pseudoref(const char *pseudoref, const unsigned char *sha1,
+const unsigned char *old_sha1);
+
+void delete_pseudoref(const char *pseudoref, const unsigned char *old_sha1);
+
extern int parse_hide_refs_config(const char *var, const char *value, const
char *);
extern int ref_is_hidden(const char *);
diff --git a/sequencer.c b/sequencer.c
index c4f4b7d..c9fc9a7 100644
--- a/sequencer.c
+++
[PATCH 8/9] rebase: use write_pseudoref
Instead of manually writing a pseudoref (in one case) and using git
update-ref (in another), use the new write_pseudoref function.
Signed-off-by: David Turner dtur...@twopensource.com
---
bisect.c | 35 +++
1 file changed, 7 insertions(+), 28 deletions(-)
diff --git a/bisect.c b/bisect.c
index 857cf59..3a9fd63 100644
--- a/bisect.c
+++ b/bisect.c
@@ -19,7 +19,6 @@ static struct object_id *current_bad_oid;
static const char *argv_checkout[] = {checkout, -q, NULL, --, NULL};
static const char *argv_show_branch[] = {show-branch, NULL, NULL};
-static const char *argv_update_ref[] = {update-ref, --no-deref,
BISECT_HEAD, NULL, NULL};
static const char *term_bad;
static const char *term_good;
@@ -675,34 +674,16 @@ static int is_expected_rev(const struct object_id *oid)
return res;
}
-static void mark_expected_rev(char *bisect_rev_hex)
-{
- int len = strlen(bisect_rev_hex);
- const char *filename = git_path(BISECT_EXPECTED_REV);
- int fd = open(filename, O_CREAT | O_TRUNC | O_WRONLY, 0600);
-
- if (fd 0)
- die_errno(could not create file '%s', filename);
-
- bisect_rev_hex[len] = '\n';
- write_or_die(fd, bisect_rev_hex, len + 1);
- bisect_rev_hex[len] = '\0';
-
- if (close(fd) 0)
- die(closing file %s: %s, filename, strerror(errno));
-}
-
-static int bisect_checkout(char *bisect_rev_hex, int no_checkout)
+static int bisect_checkout(const unsigned char *bisect_rev, int no_checkout)
{
+ char bisect_rev_hex[GIT_SHA1_HEXSZ + 1];
- mark_expected_rev(bisect_rev_hex);
+ memcpy(bisect_rev_hex, sha1_to_hex(bisect_rev), GIT_SHA1_HEXSZ + 1);
+ write_pseudoref(BISECT_EXPECTED_REV, bisect_rev, NULL);
argv_checkout[2] = bisect_rev_hex;
if (no_checkout) {
- argv_update_ref[3] = bisect_rev_hex;
- if (run_command_v_opt(argv_update_ref, RUN_GIT_CMD))
- die(update-ref --no-deref HEAD failed on %s,
- bisect_rev_hex);
+ write_pseudoref(BISECT_HEAD, bisect_rev, NULL);
} else {
int res;
res = run_command_v_opt(argv_checkout, RUN_GIT_CMD);
@@ -804,7 +785,7 @@ static void check_merge_bases(int no_checkout)
handle_skipped_merge_base(mb);
} else {
printf(Bisecting: a merge base must be tested\n);
- exit(bisect_checkout(sha1_to_hex(mb), no_checkout));
+ exit(bisect_checkout(mb, no_checkout));
}
}
@@ -948,7 +929,6 @@ int bisect_next_all(const char *prefix, int no_checkout)
struct commit_list *tried;
int reaches = 0, all = 0, nr, steps;
const unsigned char *bisect_rev;
- char bisect_rev_hex[GIT_SHA1_HEXSZ + 1];
read_bisect_terms(term_bad, term_good);
if (read_bisect_refs())
@@ -986,7 +966,6 @@ int bisect_next_all(const char *prefix, int no_checkout)
}
bisect_rev = revs.commits-item-object.sha1;
- memcpy(bisect_rev_hex, sha1_to_hex(bisect_rev), GIT_SHA1_HEXSZ + 1);
if (!hashcmp(bisect_rev, current_bad_oid-hash)) {
exit_if_skipped_commits(tried, current_bad_oid);
@@ -1003,7 +982,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
(roughly %d step%s)\n, nr, (nr == 1 ? : s),
steps, (steps == 1 ? : s));
- return bisect_checkout(bisect_rev_hex, no_checkout);
+ return bisect_checkout(bisect_rev, no_checkout);
}
static inline int log2i(int n)
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] refs: forbid pseudoref updates through ref update API
It is now forbidden to update pseudorefs through the ref update
framework.
Because of the pseudoref update rules change, test cases that used git
update-ref on a pseudoref now operate on plain refs.
Signed-off-by: David Turner dtur...@twopensource.com
---
bisect.c | 2 +-
refs.c| 2 ++
t/t1400-update-ref.sh | 24
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/bisect.c b/bisect.c
index 3a9fd63..47cc778 100644
--- a/bisect.c
+++ b/bisect.c
@@ -969,7 +969,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
if (!hashcmp(bisect_rev, current_bad_oid-hash)) {
exit_if_skipped_commits(tried, current_bad_oid);
- printf(%s is the first %s commit\n, bisect_rev_hex,
+ printf(%s is the first %s commit\n, sha1_to_hex(bisect_rev),
term_bad);
show_diff_tree(prefix, revs.commits-item);
/* This means the bisection process succeeded. */
diff --git a/refs.c b/refs.c
index efa84e3..f8dc877 100644
--- a/refs.c
+++ b/refs.c
@@ -3902,6 +3902,8 @@ int ref_transaction_update(struct ref_transaction
*transaction,
struct ref_update *update;
assert(err);
+ if (is_pseudoref(refname))
+ return error(_(BUG: Cannot update pseudorefs (all-caps files
in .git) through the refs API));
if (transaction-state != REF_TRANSACTION_OPEN)
die(BUG: update called for transaction that is not open);
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 0038f28..b05657c 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -608,13 +608,13 @@ test_expect_success 'stdin delete ref fails with zero old
value' '
'
test_expect_success 'stdin update symref works option no-deref' '
- git symbolic-ref TESTSYMREF $b
+ git symbolic-ref refs/TESTSYMREF $b
cat stdin -EOF
option no-deref
- update TESTSYMREF $a $b
+ update refs/TESTSYMREF $a $b
EOF
git update-ref --stdin stdin
- git rev-parse TESTSYMREF expect
+ git rev-parse refs/TESTSYMREF expect
git rev-parse $a actual
test_cmp expect actual
git rev-parse $m~1 expect
@@ -623,13 +623,13 @@ test_expect_success 'stdin update symref works option
no-deref' '
'
test_expect_success 'stdin delete symref works option no-deref' '
- git symbolic-ref TESTSYMREF $b
+ git symbolic-ref refs/TESTSYMREF $b
cat stdin -EOF
option no-deref
- delete TESTSYMREF $b
+ delete refs/TESTSYMREF $b
EOF
git update-ref --stdin stdin
- test_must_fail git rev-parse --verify -q TESTSYMREF
+ test_must_fail git rev-parse --verify -q refs/TESTSYMREF
git rev-parse $m~1 expect
git rev-parse $b actual
test_cmp expect actual
@@ -983,10 +983,10 @@ test_expect_success 'stdin -z delete ref fails with zero
old value' '
'
test_expect_success 'stdin -z update symref works option no-deref' '
- git symbolic-ref TESTSYMREF $b
- printf $F option no-deref update TESTSYMREF $a $b stdin
+ git symbolic-ref refs/TESTSYMREF $b
+ printf $F option no-deref update refs/TESTSYMREF $a $b stdin
git update-ref -z --stdin stdin
- git rev-parse TESTSYMREF expect
+ git rev-parse refs/TESTSYMREF expect
git rev-parse $a actual
test_cmp expect actual
git rev-parse $m~1 expect
@@ -995,10 +995,10 @@ test_expect_success 'stdin -z update symref works option
no-deref' '
'
test_expect_success 'stdin -z delete symref works option no-deref' '
- git symbolic-ref TESTSYMREF $b
- printf $F option no-deref delete TESTSYMREF $b stdin
+ git symbolic-ref refs/TESTSYMREF $b
+ printf $F option no-deref delete refs/TESTSYMREF $b stdin
git update-ref -z --stdin stdin
- test_must_fail git rev-parse --verify -q TESTSYMREF
+ test_must_fail git rev-parse --verify -q refs/TESTSYMREF
git rev-parse $m~1 expect
git rev-parse $b actual
test_cmp expect actual
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] refs: Introduce pseudoref and per-worktree ref concepts
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling,
because the files refs backend already handles them correctly. Later,
we will make the LMDB backend call out to the files backend to handle
per-worktree refs.
Signed-off-by: David Turner dtur...@twopensource.com
---
Documentation/glossary-content.txt | 17 +
refs.c | 23 +++
refs.h | 2 ++
3 files changed, 42 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index ab18f4b..d04819e 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -411,6 +411,23 @@ exclude;;
core Git. Porcelains expose more of a def_SCM,SCM
interface than the def_plumbing,plumbing.
+[[def_per_worktree_ref]]per-worktree ref::
+ Refs that are per-def_worktree,worktree, rather than
+ global. This is presently only def_HEAD,HEAD, but might
+ later include other unsuual refs.
+
+[[def_pseudoref]]pseudoref::
+ Files under `$GIT_DIR` whose names are all-caps, and that
+ contain a line consisting of a def_sha1,SHA-1 followed by
+ a newline, and optionally some additional data. `MERGE_HEAD`
+ and `CHERRY_PICK_HEAD` are examples. Unlike
+ def_per_worktree_ref,per-worktree refs, these files cannot
+ be symbolic refs, and never not have reflogs. They also
+ cannot be updated through the normal ref update machinery.
+ Instead, they are updated by directly writing to the files.
+ However, they can be read as if they were refs, so `git
+ rev-parse MERGE_HEAD` will work.
+
[[def_pull]]pull::
Pulling a def_branch,branch means to def_fetch,fetch it and
def_merge,merge it. See also linkgit:git-pull[1].
diff --git a/refs.c b/refs.c
index 0b96ece..d31ca42 100644
--- a/refs.c
+++ b/refs.c
@@ -3857,6 +3857,29 @@ void ref_transaction_free(struct ref_transaction
*transaction)
free(transaction);
}
+int is_per_worktree_ref(const char *refname)
+{
+ return !strcmp(refname, HEAD);
+}
+
+static int is_pseudoref(const char *refname)
+{
+ const char *c;
+
+ if (strchr(refname, '/'))
+ return 0;
+
+ if (is_per_worktree_ref(refname))
+ return 0;
+
+ for (c = refname; *c; ++c) {
+ if (!isupper(*c) *c != '-' *c != '_')
+ return 0;
+ }
+
+ return 1;
+}
+
static struct ref_update *add_update(struct ref_transaction *transaction,
const char *refname)
{
diff --git a/refs.h b/refs.h
index e4e46c3..bd5526e 100644
--- a/refs.h
+++ b/refs.h
@@ -445,6 +445,8 @@ extern int parse_hide_refs_config(const char *var, const
char *value, const char
extern int ref_is_hidden(const char *);
+int is_per_worktree_ref(const char *refname);
+
enum expire_reflog_flags {
EXPIRE_REFLOGS_DRY_RUN = 1 0,
EXPIRE_REFLOGS_UPDATE_REF = 1 1,
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] am/rebase: update pseudorefs by writing files
git update-ref can no longer be used to update pseudorefs, so in
git-am and git-rebase, we just directly edit the files.
Signed-off-by: David Turner dtur...@twopensource.com
---
builtin/am.c | 6 +++---
contrib/examples/git-am.sh | 4 ++--
git-rebase--interactive.sh | 2 +-
git-rebase.sh | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index 3f0fc75..ff3 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1049,12 +1049,12 @@ static void am_setup(struct am_state *state, enum
patch_format patch_format,
if (!get_sha1(HEAD, curr_head)) {
write_file(am_path(state, abort-safety), 1, %s,
sha1_to_hex(curr_head));
if (!state-rebasing)
- update_ref(am, ORIG_HEAD, curr_head, NULL, 0,
- UPDATE_REFS_DIE_ON_ERR);
+ write_pseudoref(ORIG_HEAD, curr_head, NULL);
} else {
write_file(am_path(state, abort-safety), 1, %s, );
if (!state-rebasing)
- delete_ref(ORIG_HEAD, NULL, 0);
+ if (unlink(git_path(ORIG_HEAD)) errno != ENOENT)
+ die(failed to unlink ORIG_HEAD);
}
/*
diff --git a/contrib/examples/git-am.sh b/contrib/examples/git-am.sh
index a3d0c84..a01a06e 100755
--- a/contrib/examples/git-am.sh
+++ b/contrib/examples/git-am.sh
@@ -614,9 +614,9 @@ Use \git am --abort\ to remove it.)
: $dotest/applying
if test -n $HAS_HEAD
then
- git update-ref ORIG_HEAD HEAD
+ git rev-parse HEAD $GIT_DIR/ORIG_HEAD
else
- git update-ref -d ORIG_HEAD /dev/null 21
+ rm -f $GIT_DIR/ORIG_HEAD
fi
fi
fi
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f01637b..ae116a6 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -948,7 +948,7 @@ warn_lines () {
checkout_onto () {
GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name
output git checkout $onto || die_abort could not detach HEAD
- git update-ref ORIG_HEAD $orig_head
+ echo $orig_head $GIT_DIR/ORIG_HEAD
}
get_missing_commit_check_level () {
diff --git a/git-rebase.sh b/git-rebase.sh
index 1757404..23e2e64 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -611,7 +611,7 @@ say $(gettext First, rewinding head to replay your work
on top of it...)
GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name \
git checkout -q $onto^0 || die could not detach HEAD
-git update-ref ORIG_HEAD $orig_head
+echo $orig_head $GIT_DIR/ORIG_HEAD
# If the $onto is a proper descendant of the tip of the branch, then
# we just fast-forwarded.
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] tests: use --create-reflog option to git update-ref
Instead of manually precreating reflogs by writing files, use
update-ref --create-reflog to create the reflogs at the same time
we first create the ref.
In one case, we need an entirely empty reflog, so we do a no-op
update-ref with --create-reflog and then expire the reflog.
This makes it slighly easier to test alternate ref backends.
Signed-off-by: David Turner dtur...@twopensource.com
---
t/t1400-update-ref.sh | 5 ++---
t/t1411-reflog-show.sh | 3 ++-
t/t1503-rev-parse-verify.sh | 9 +++--
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 9d21c19..0038f28 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -174,12 +174,11 @@ test_expect_success (not) changed .git/$m
'
rm -f .git/$m
-: a repository with working tree always has reflog these days...
-: .git/logs/refs/heads/master
+rm .git/logs/refs/heads/master
test_expect_success \
create $m (logged by touch) \
'GIT_COMMITTER_DATE=2005-05-26 23:30 \
-git update-ref HEAD '$A' -m Initial Creation
+git update-ref --create-reflog HEAD '$A' -m Initial Creation
test '$A' = $(cat .git/'$m')'
test_expect_success \
update $m (logged by touch) \
diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
index 3eb4f10..ee069ac 100755
--- a/t/t1411-reflog-show.sh
+++ b/t/t1411-reflog-show.sh
@@ -138,7 +138,8 @@ test_expect_success '--date magic does not override
explicit @{0} syntax' '
: expect
test_expect_success 'empty reflog file' '
git branch empty
- : .git/logs/refs/heads/empty
+ git update-ref --create-reflog refs/heads/empty empty
+ git reflog expire --expire=all refs/heads/empty
git log -g empty actual
test_cmp expect actual
diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
index 823fe1d..ab27d0d 100755
--- a/t/t1503-rev-parse-verify.sh
+++ b/t/t1503-rev-parse-verify.sh
@@ -85,8 +85,7 @@ test_expect_success 'fails silently when using -q' '
test_expect_success 'fails silently when using -q with deleted reflogs' '
ref=$(git rev-parse HEAD)
- : .git/logs/refs/test
- git update-ref -m message for refs/test refs/test $ref
+ git update-ref --create-reflog -m message for refs/test refs/test
$ref
git reflog delete --updateref --rewrite refs/test@{0}
test_must_fail git rev-parse -q --verify refs/test@{0} error 21
test_must_be_empty error
@@ -94,16 +93,14 @@ test_expect_success 'fails silently when using -q with
deleted reflogs' '
test_expect_success 'fails silently when using -q with not enough reflogs' '
ref=$(git rev-parse HEAD)
- : .git/logs/refs/test2
- git update-ref -m message for refs/test2 refs/test2 $ref
+ git update-ref --create-reflog -m message for refs/test2 refs/test2
$ref
test_must_fail git rev-parse -q --verify refs/test2@{999} error 21
test_must_be_empty error
'
test_expect_success 'succeeds silently with -q and reflogs that do not go far
back enough in time' '
ref=$(git rev-parse HEAD)
- : .git/logs/refs/test3
- git update-ref -m message for refs/test3 refs/test3 $ref
+ git update-ref --create-reflog -m message for refs/test3 refs/test3
$ref
git rev-parse -q --verify refs/test3@{1.year.ago} actual 2error
test_must_be_empty error
echo $ref expect
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] Documentation/git-worktree: fix broken 'linkgit' invocation
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Documentation/git-worktree.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index 332dd77..400b313 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt @@ -27,7 +27,7 @@ bare repository) and zero or more linked working trees. When you are done with a linked working tree you can simply delete it. The working tree's administrative files in the repository (see DETAILS below) will eventually be removed automatically (see -`gc.worktreePruneExpire` in linkgit::git-config[1]), or you can run +`gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run `git worktree prune` in the main or any linked working tree to clean up any stale administrative files. -- 2.5.0.rc3.407.g68aafd0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] Documentation/git-tools: drop references to defunct tools
Cogito -- unmaintained since late 2006[1] pg -- URL dead; web searches reveal no information quilt2git -- URL dead; web searches reveal no information (h)gct -- URL dead; no repository activity since 2007[2] [1]: http://git.or.cz/cogito/ [2]: http://repo.or.cz/w/hgct.git Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Perhaps it would be better to drop all items, and retain only the link to the Git wiki? Documentation/git-tools.txt | 31 --- 1 file changed, 31 deletions(-) diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index ab4aab9..48a3595 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -16,24 +16,6 @@ http://git.or.cz/gitwiki/InterfacesFrontendsAndTools Alternative/Augmentative Porcelains --- -- *Cogito* (http://www.kernel.org/pub/software/scm/cogito/) -+ -Cogito is a version control system layered on top of the Git tree history -storage system. It aims at seamless user interface and ease of use, -providing generally smoother user experience than the raw Core Git -itself and indeed many other version control systems. -+ -Cogito is no longer maintained as most of its functionality -is now in core Git. - - -- *pg* (http://www.spearce.org/category/projects/scm/pg/) -+ -pg is a shell script wrapper around Git to help the user manage a set of -patches to files. pg is somewhat like quilt or StGit, but it does have a -slightly different feature set. - - - *StGit* (http://www.procode.org/stgit/) + Stacked Git provides a quilt-like patch management functionality in the @@ -84,12 +66,6 @@ git-svn is a simple conduit for changesets between a single Subversion branch and Git. -- *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc) -+ -These utilities convert patch series in a quilt repository and commit -series in Git back and forth. - - - *hg-to-git* (contrib/) + hg-to-git converts a Mercurial repository into a Git one, and @@ -101,13 +77,6 @@ in sync with the master Mercurial repository. Others -- -- *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/) -+ -Commit Tool or (h)gct is a GUI enabled commit tool for Git and -Mercurial (hg). It allows the user to view diffs, select which files -to committed (or ignored / reverted) write commit messages and -perform the commit itself. - - *git.el* (contrib/) + This is an Emacs interface for Git. The user interface is modelled on -- 2.5.0.rc3.407.g68aafd0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] Documentation/git-tools: improve discoverability of Git wiki
These days, the best way to find Git-related tools is via a search engine. Second best may be the Git wiki. git-tools.txt falls in last place. Therefore, promote the Git wiki reference to the top of git-tools.txt so the reader will encounter it first, rather than hiding it away at the very bottom. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- I sneaked in a minor grammatical fix. Documentation/git-tools.txt | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index 78a0d95..129b8c0 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -6,10 +6,11 @@ Introduction Apart from Git contrib/ area there are some others third-party tools -you may want to look. - +you may want to look at. This document presents a brief summary of each tool and the corresponding link. +For a more comprehensive list, see: +http://git.or.cz/gitwiki/InterfacesFrontendsAndTools Alternative/Augmentative Porcelains @@ -112,7 +113,3 @@ Others This is an Emacs interface for Git. The user interface is modelled on pcl-cvs. It has been developed on Emacs 21 and will probably need some tweaking to work on XEmacs. - - -http://git.or.cz/gitwiki/InterfacesFrontendsAndTools has more -comprehensive list. -- 2.5.0.rc3.407.g68aafd0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] Documentation/git: drop outdated Cogito reference
Cogito hasn't been maintained since late 2006, so drop the reference to it. The warning that SCMS front-ends might override listed environment variables, however, may still be valuable, so keep it but generalize the wording. Suggested-by: Junio C Hamano gits...@pobox.com Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Reference: http://article.gmane.org/gmane.comp.version-control.git/274084 Documentation/git.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index 1e8a569..ef774be 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -774,7 +774,7 @@ The Git Repository ~~ These environment variables apply to 'all' core Git commands. Nb: it is worth noting that they may be used/overridden by SCMS sitting above -Git so take care if using Cogito etc. +Git so take care if using a foreign front-end. 'GIT_INDEX_FILE':: This environment allows the specification of an alternate -- 2.5.0.rc3.407.g68aafd0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] Documentation/git-tools: fix item text formatting
Descriptive text for each tool item is incorrectly formatted using a fixed width font. Fix formatting to use a variable width font by unindenting the item text. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Documentation/git-tools.txt | 134 ++-- 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index 129b8c0..ab4aab9 100644 --- a/Documentation/git-tools.txt +++ b/Documentation/git-tools.txt @@ -16,100 +16,100 @@ http://git.or.cz/gitwiki/InterfacesFrontendsAndTools Alternative/Augmentative Porcelains --- - - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/) +- *Cogito* (http://www.kernel.org/pub/software/scm/cogito/) ++ +Cogito is a version control system layered on top of the Git tree history +storage system. It aims at seamless user interface and ease of use, +providing generally smoother user experience than the raw Core Git +itself and indeed many other version control systems. ++ +Cogito is no longer maintained as most of its functionality +is now in core Git. - Cogito is a version control system layered on top of the Git tree history - storage system. It aims at seamless user interface and ease of use, - providing generally smoother user experience than the raw Core Git - itself and indeed many other version control systems. - Cogito is no longer maintained as most of its functionality - is now in core Git. +- *pg* (http://www.spearce.org/category/projects/scm/pg/) ++ +pg is a shell script wrapper around Git to help the user manage a set of +patches to files. pg is somewhat like quilt or StGit, but it does have a +slightly different feature set. - - *pg* (http://www.spearce.org/category/projects/scm/pg/) - - pg is a shell script wrapper around Git to help the user manage a set of - patches to files. pg is somewhat like quilt or StGit, but it does have a - slightly different feature set. - - - - *StGit* (http://www.procode.org/stgit/) - - Stacked Git provides a quilt-like patch management functionality in the - Git environment. You can easily manage your patches in the scope of Git - until they get merged upstream. +- *StGit* (http://www.procode.org/stgit/) ++ +Stacked Git provides a quilt-like patch management functionality in the +Git environment. You can easily manage your patches in the scope of Git +until they get merged upstream. History Viewers --- - - *gitk* (shipped with git-core) - - gitk is a simple Tk GUI for browsing history of Git repositories easily. - - - - *gitview* (contrib/) - - gitview is a GTK based repository browser for Git +- *gitk* (shipped with git-core) ++ +gitk is a simple Tk GUI for browsing history of Git repositories easily. - - *gitweb* (shipped with git-core) +- *gitview* (contrib/) ++ +gitview is a GTK based repository browser for Git - Gitweb provides full-fledged web interface for Git repositories. +- *gitweb* (shipped with git-core) ++ +Gitweb provides full-fledged web interface for Git repositories. - - *qgit* (http://digilander.libero.it/mcostalba/) - QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used - to browse history and directory tree, view annotated files, commit - changes cherry picking single files or applying patches. - Currently it is the fastest and most feature rich among the Git - viewers and commit tools. +- *qgit* (http://digilander.libero.it/mcostalba/) ++ +QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used +to browse history and directory tree, view annotated files, commit +changes cherry picking single files or applying patches. +Currently it is the fastest and most feature rich among the Git +viewers and commit tools. - - *tig* (http://jonas.nitro.dk/tig/) - - tig by Jonas Fonseca is a simple Git repository browser - written using ncurses. Basically, it just acts as a front-end - for git-log and git-show/git-diff. Additionally, you can also - use it as a pager for Git commands. +- *tig* (http://jonas.nitro.dk/tig/) ++ +tig by Jonas Fonseca is a simple Git repository browser +written using ncurses. Basically, it just acts as a front-end +for git-log and git-show/git-diff. Additionally, you can also +use it as a pager for Git commands. Foreign SCM interface - - - *git-svn* (shipped with git-core) - - git-svn is a simple conduit for changesets between a single Subversion - branch and Git. - - - - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc) +- *git-svn* (shipped with git-core) ++ +git-svn is a simple conduit for changesets between a single Subversion +branch and Git. - These utilities convert patch series in a quilt repository and commit - series in Git back and forth. +- *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc) ++ +These utilities convert patch series in a
[PATCH 0/6] minor documentation improvements
This is a set of minor documentation improvements, prompted by suggestions from Junio and Michael Haggerty, plus a few things I discovered in the process. It is built atop 'es/worktree-add' in 'next' in order to avoid conflicts with changes in that series (but is otherwise not related to those patches). Eric Sunshine (6): Documentation/git-worktree: fix broken 'linkgit' invocation Documentation/config: mention now and never for 'expire' settings Documentation/git: drop outdated Cogito reference Documentation/git-tools: improve discoverability of Git wiki Documentation/git-tools: fix item text formatting Documentation/git-tools: drop references to defunct tools Documentation/config.txt | 13 +++-- Documentation/git-tools.txt| 124 +++-- Documentation/git-worktree.txt | 2 +- Documentation/git.txt | 2 +- 4 files changed, 55 insertions(+), 86 deletions(-) -- 2.5.0.rc3.407.g68aafd0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] Documentation/config: mention now and never for 'expire' settings
In addition to approxidate-style values (2.months.ago, yesterday), consumers of 'gc.*expire*' configuration variables also accept and respect 'now'/'all' (do it immediately) and 'never'/'false' (suppress entirely). Suggested-by: Michael Haggerty mhag...@alum.mit.edu Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Reference: http://article.gmane.org/gmane.comp.version-control.git/274325 I sneaked in a minor whitespace fix. Documentation/config.txt | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1a8a399..cc920c0 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1307,20 +1307,22 @@ gc.packRefs:: gc.pruneExpire:: When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'. Override the grace period with this config variable. The value - now may be used to disable this grace period and always prune - unreachable objects immediately. + now may be used to disable this grace period and always prune + unreachable objects immediately; or never to suppress pruning. gc.worktreePruneExpire:: When 'git gc' is run, it calls 'git worktree prune --expire 3.months.ago'. This config variable can be used to set a different grace period. The value now may be used to disable the grace - period and prune $GIT_DIR/worktrees immediately. + period and prune $GIT_DIR/worktrees immediately; or never to + suppress pruning. gc.reflogExpire:: gc.pattern.reflogExpire:: 'git reflog expire' removes reflog entries older than - this time; defaults to 90 days. With pattern (e.g. + this time; defaults to 90 days. The value all expires all + entries; and false disables expiration. With pattern (e.g. refs/stash) in the middle the setting applies only to the refs that match the pattern. @@ -1328,7 +1330,8 @@ gc.reflogExpireUnreachable:: gc.ref.reflogExpireUnreachable:: 'git reflog expire' removes reflog entries older than this time and are not reachable from the current tip; - defaults to 30 days. With pattern (e.g. refs/stash) + defaults to 30 days. The value all expires all entries; and + false disables expiration. With pattern (e.g. refs/stash) in the middle, the setting applies only to the refs that match the pattern. -- 2.5.0.rc3.407.g68aafd0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
Jeff King p...@peff.net writes: I have not been following the thread closely, but I do not recall seeing anyone mention that the reason for the sha1-output is handing only a single commit-ish to diff-tree is what puts it into its log-like mode. Actually asking for a two-endpoint tree diff: git diff-tree --quiet --ignore-space-change $commit^ $commit will do what you want. Yeah, if we were living in an ideal world equipped with a time machine, I would redesign git diff-tree $commit so that it does not show the commit object name in its output at all, with or without --quiet. In git rev-list ... | git diff-tree --stdin output, the commit object name is absolutely necessary, with or without --quiet, as it serves as the sign that the output switched to talk about a different commit. But the case that feeds a single commit to the command, used as a poor-man's git show $commit, does not need one---the caller knows exactly which commit the output is about. It is an unfortunate historical accident that a single commit usage is defined to be a degenerate case of feeding a sequence of commits to the command and the length of the sequence happens to be one. diff-tree $commit could instead have been defined as a short-hand for diff-tree $commit^ $commit, but (1) we do not live in an ideal world, and (2) it ignores $commit^2 and later parents. This is a tangent, but I suspect that the current implementation of diff-tree --stdin --quiet may be buggy and does not consistently show the commits that touch the given path. $ git rev-list master..jc/rerere | git diff-tree --stdin -s rerere.h gives what is expected (shows the commit object names, but being silent on the differences), while s/-s/--quiet/ seems to omit every other commit from the output, or something silly like that. I haven't dug into why that happens, but possible ways to fix that are to make --quiet output all (making it consistent with -s) or no (making the command totally silent) output at all ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
On Thu, Jul 23, 2015 at 8:08 PM, Jeff King p...@peff.net wrote: mode. Actually asking for a two-endpoint tree diff: git diff-tree --quiet --ignore-space-change $commit^ $commit will do what you want. Yes, I know, thanks. But I deliberately wanted to specify only a single commit as an optimization, hoping that it would be slightly faster than computing a commit range. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] contrib: teach completion about git-worktree options and arguments
Complete subcommands 'add' and 'prune', as well as their respective
options --force, --detach, --dry-run, --verbose, and --expire. Also
complete 'refname' in git worktree add [-b newbranch] path
refname.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
This is RFC since this is my first foray into the Git completion script,
and there are likely better and more idiomatic ways to accomplish this.
contrib/completion/git-completion.bash | 32
1 file changed, 32 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c97c648..07c34ef 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2564,6 +2564,38 @@ _git_whatchanged ()
_git_log
}
+_git_worktree ()
+{
+ local subcommands='add prune'
+ local subcommand=$(__git_find_on_cmdline $subcommands)
+ local c=2 n=0 refpos=2
+ if [ -z $subcommand ]; then
+ __gitcomp $subcommands
+ else
+ case $subcommand,$cur in
+ add,--*)
+ __gitcomp --force --detach
+ ;;
+ add,*)
+ while [ $c -lt $cword ]; do
+ case ${words[c]} in
+ --*) ;;
+ -[bB]) ((refpos++)) ;;
+ *) ((n++)) ;;
+ esac
+ ((c++))
+ done
+ if [ $n -eq $refpos ]; then
+ __gitcomp_nl $(__git_refs)
+ fi
+ ;;
+ prune,--*)
+ __gitcomp --dry-run --verbose --expire
+ ;;
+ esac
+ fi
+}
+
__git_main ()
{
local i c=1 command __git_dir
--
2.5.0.rc3.407.g68aafd0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
On Wed, Jul 22, 2015 at 5:05 PM, Jacob Keller jacob.e.kel...@intel.com wrote: From: Jacob Keller jacob.kel...@gmail.com Modify logic of check_refname_component and add a new disposition regarding *. Allow refspecs that contain a single * if REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as a pointer, and clear REFNAME_REFSPEC_PATTERN after the first * so that only a single * is accepted. This loosens restrictions on refspecs by allowing patterns that have a * within a component instead of only as the whole component. Also remove the code that hangled refspec patterns in check_refname_format s/hangled/handled/ since it is now handled via the check_refname_component logic. Now refs such as `for/bar*:foo/bar*` and even `foo/bar*:foo/baz*` will be accepted. This allows users more control over what is fetched where. Since users must modify the default by hand to make use of this functionality it is not considered a large risk. Any refspec which functioned before shall continue functioning with the new logic. Signed-off-by: Jacob Keller jacob.kel...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/9] ref-filter: add option to align atoms to the left
On Thu, Jul 23, 2015 at 12:14 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: + strtoul_ui(valp, 10, ref-align_value); + if (ref-align_value 1) + die(_(Value should be greater than zero)); You're not checking the return value of strtoul_ui, which returns -1 before assigning align_value if the value can't be parsed. As a result, you're testing an undefined value in the 'if' statement in this case. You should test the return value and issue a distinct error message in this case like if (strtoul_ui(valp, 10, ref-align_value)) die(_(positive integer expected after ':' in align:%u\n, ref_align_value)); -- Matthieu Moy http://www-verimag.imag.fr/~moy/ Makes sense, thanks :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
On Thu, 23 Jul 2015 11:14:11 +0200 Konrád Lőrinczi klorin...@gmail.com wrote: [...] I accept these solutions as workarounds, but the real solution would be: Dev suggestions: 1) Add a --force-reread option to git status, so user can force reread tree. git status --force-reread 2) Add status.force-reread (true or false) option to .git/config so user can set this variable permanently for a repo. status.force-reread = false (should be default) Could be possible to implement 1) and 2) features to next git release? Could you explain what's your real use case with preserving mtimes while changing the files? I mean, implementing mtime-stability in your tools appears to be a good excersize in programming but what real-world problem does it solve? I'm asking because if you are not going to implement the changes to Git you suggested yourself, then someone else should be *convinced* to do so. So far, your trouble appears to be too artifical to bother. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
Hi, On 2015-07-23 09:29, Konrád Lőrinczi wrote: I wrote a search replace perl script, which recursively searches files and replaces text in them. After replace, it restores original modification time (mtime) of file. Since this is almost identical to https://github.com/msysgit/git/issues/312#issuecomment-124030520 I assume that you wrote that. In my answer on the (already closed) GitHub ticket, I wrote this: -- snipsnap -- I wrote a search replace perl script, which recursively searches files and replaces text in them. After replace, it restores original modification time (mtime) of file. By this restoring of the original modification time you broke the contract: the mtime should reflect the time of the latest change. You replaced something, i.e. changed the file contents. Git expects the mtime to be adjusted in that case. By painstakingly faking it back to its original value you essentially told Git: don't worry, this file has not changed since you last saw it. There is nothing Git can do to outguess you when you go out of your way to break the most fundamental promise of the mtime value. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
On Wed, Jul 22, 2015 at 10:48 PM, Jeff King p...@peff.net wrote: On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote: Script writers should not care here, because they should not be parsing the output of the porcelain log command in the first place. It already has many gotchas (e.g., log.date, log.abbrevCommit). I am sympathetic, though. There are some things that git-log can do that rev-list cannot, so people end up using it in scripts. I think you can avoid it with a rev-list | diff-tree pipeline, though I'm not 100% sure if that covers all cases. But I would much rather see a solution along the lines of making the plumbing cover more cases, rather than trying to make the porcelain behave in a script. Ah, I see in a nearby thread that you just recently fixed a problem with git-subtree and log.date, so I see now why you are so interested. :) And I was also reminded by that usage of why rev-list is annoying in scripts: even with --format, it insists on writing the commit ... header. I wonder if we could fix that... -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Agreed. Fix the plumbing instead and document how/why to use it instead of the porcelain. We might do better to help clearly document which commands are porcelain and which are plumbing maybe by referencing which plumbings to use in place of various porcelain commands. I know, for example, that git status already does this. Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov: On Thu, 23 Jul 2015 11:14:11 +0200 Konrád Lőrinczi klorin...@gmail.com wrote: [...] I accept these solutions as workarounds, but the real solution would be: Dev suggestions: 1) Add a --force-reread option to git status, so user can force reread tree. git status --force-reread 2) Add status.force-reread (true or false) option to .git/config so user can set this variable permanently for a repo. status.force-reread = false (should be default) Could be possible to implement 1) and 2) features to next git release? Could you explain what's your real use case with preserving mtimes while changing the files? I mean, implementing mtime-stability in your tools appears to be a good excersize in programming but what real-world problem does it solve? I'd like to add that this is not a git-specific problem: resetting mtime on purpose will fool lots of programs, including backup software, file synchronization tools (rsync, xcopy /D), build systems (make), and web servers / proxies (If-Modified-Since requests). So you would typically reset mtime if you *want* programs to ignore the changes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
unexplained behavior/issue with git archive?
hi, i seem to trigger behavior i do not understand with git archive. I have this little 3 liner (vmdiff.sh): #!/bin/bash git diff --name-status $2 $3 $1.files git diff --name-only $2 $3 |xargs -d'\n' git archive -o $1 $3 -- For testing purpose, lets assume this call: # ./vmdiff.sh latest.zip HEAD^1 HEAD # cat latest.zip.files | wc -l 149021 # cat latest.zip.files | egrep ^D | wc -l 159 # mkdir empty; cd empty; unzip latest.zip ; find * | wc -l 1090 My goal is to basically diff (parts of) filesystems against each other and create an archive with all changed files + a file list to know what files were deleted. (I currently do not care about the files permissions+ownership, and it doesnt really matter in the current problem. Also dont ask, why one would store a root-filesystem in git :) What I do not understand: why does the zip file only contains 1090 files+dirs if the wc -l shows like 150k files and only like 159 were deleted? There should be like 149k files in that archive. Also only the few files are all from var and none from etc or srv where definitely files changed in too! (and show up in latest.zip.files) Is there a limit of files git archive can process? lg Jan Vales -- I only read plaintext emails. Someone @ irc://irc.fsinf.at:6667/tuwien webIRC: https://frost.fsinf.at/iris/ signature.asc Description: OpenPGP digital signature
Re: unexplained behavior/issue with git archive?
On Thu, Jul 23, 2015 at 05:23:49PM +0200, Jan Vales wrote: i seem to trigger behavior i do not understand with git archive. I have this little 3 liner (vmdiff.sh): #!/bin/bash git diff --name-status $2 $3 $1.files git diff --name-only $2 $3 |xargs -d'\n' git archive -o $1 $3 -- For testing purpose, lets assume this call: # ./vmdiff.sh latest.zip HEAD^1 HEAD # cat latest.zip.files | wc -l 149021 # cat latest.zip.files | egrep ^D | wc -l 159 # mkdir empty; cd empty; unzip latest.zip ; find * | wc -l 1090 My goal is to basically diff (parts of) filesystems against each other and create an archive with all changed files + a file list to know what files were deleted. (I currently do not care about the files permissions+ownership, and it doesnt really matter in the current problem. Also dont ask, why one would store a root-filesystem in git :) What I do not understand: why does the zip file only contains 1090 files+dirs if the wc -l shows like 150k files and only like 159 were deleted? There should be like 149k files in that archive. Also only the few files are all from var and none from etc or srv where definitely files changed in too! (and show up in latest.zip.files) Is there a limit of files git archive can process? Not explicitly, but there is a limit on the size of command lines and xargs will invoke the command multiple times if enough arguments are given. What happens if you do: git diff --name-only HEAD^ HEAD | xargs -d'\n' echo | wc -l ? With a small number of items, there should only be one output line, but if xargs invokes the command multiple times there will be multiple lines. For example (using -L2 to force a maximum of two arguments per invocation): $ printf '%s\n' a b c | xargs -d'\n' echo | wc -l 1 $ printf '%s\n' a b c | xargs -d'\n' -L2 echo | wc -l 2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
Junio C Hamano gits...@pobox.com writes: Will squash the changes; no need to resend (unless people discover other issues; let's hope that I wouldn't be the one to do so ;-). Thanks. diff --git i/t/t5511-refspec.sh w/t/t5511-refspec.sh index de6db86ccff0..7bfca7962d41 100755 --- i/t/t5511-refspec.sh +++ w/t/t5511-refspec.sh @@ -71,11 +71,11 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me' That was whitespace damaged, so I had to hand-tweak the file in place. While at it, I noticed that we do not check a case where multiple asterisks appear in a single component (which is rejected for a reason different from having multiple components with an asterisk in them), which also deserves its own test. I'll squash in the following instead. There is a slightly related tangent I noticed while doing so. I wonder if there is an obvious and unambiguous interpretation of what this command line wants to do: $ git fetch origin refs/heads/*g*/for-linus:refs/remotes/i-*/mine We _might_ want to allow one (and only one) component with more than one asterisk on the LHS of a refspec, while requiring only one asterisk on the RHS to allow this '*g*' is just like '*' but excluding things that do not have 'g' in it. Or it may not be worth the additional complexity. t/t5511-refspec.sh | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/t/t5511-refspec.sh b/t/t5511-refspec.sh index de6db86..f541f30 100755 --- a/t/t5511-refspec.sh +++ b/t/t5511-refspec.sh @@ -71,15 +71,18 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me' test_refspec push ':refs/remotes/frotz/delete me' invalid test_refspec fetch ':refs/remotes/frotz/HEAD to me'invalid -test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid -test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid +test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' +test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' -test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid -test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid +test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' +test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid +test_refspec fetch 'refs/heads/*g*/for-linus:refs/remotes/mine/*' invalid +test_refspec push 'refs/heads/*g*/for-linus:refs/remotes/mine/*' invalid + test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*' test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
On Thu, Jul 23, 2015 at 10:13 AM, Junio C Hamano gits...@pobox.com wrote: That was whitespace damaged, so I had to hand-tweak the file in place. While at it, I noticed that we do not check a case where multiple asterisks appear in a single component (which is rejected for a reason different from having multiple components with an asterisk in them), which also deserves its own test. Oops. Sorry about that.. I'll squash in the following instead. There is a slightly related tangent I noticed while doing so. I wonder if there is an obvious and unambiguous interpretation of what this command line wants to do: $ git fetch origin refs/heads/*g*/for-linus:refs/remotes/i-*/mine Personally, I do think this is obvious but I don't think that our parser is at all smart enough to handle it. The advantage with the current code, is that the match parser already handles it perfectly. It was just the rules up front which limited how much we could do. I don't think the added complexity is that valuable here.. For most common cases it's just prefixes or suffixes that matter. We _might_ want to allow one (and only one) component with more than one asterisk on the LHS of a refspec, while requiring only one asterisk on the RHS to allow this '*g*' is just like '*' but excluding things that do not have 'g' in it. As above, I think it's obvious the intended meaning, but... the actual interpretation could be a variety of things. It's not guaranteed to be interpreted in that way, and while we could document it, I don't think that it is worth the complexity unless someone actually needs this behavior. Or it may not be worth the additional complexity. Below diff looks fine, thanks! Regards, Jake t/t5511-refspec.sh | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/t/t5511-refspec.sh b/t/t5511-refspec.sh index de6db86..f541f30 100755 --- a/t/t5511-refspec.sh +++ b/t/t5511-refspec.sh @@ -71,15 +71,18 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me' test_refspec push ':refs/remotes/frotz/delete me' invalid test_refspec fetch ':refs/remotes/frotz/HEAD to me'invalid -test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid -test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid +test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' +test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' -test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid -test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid +test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' +test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid +test_refspec fetch 'refs/heads/*g*/for-linus:refs/remotes/mine/*' invalid +test_refspec push 'refs/heads/*g*/for-linus:refs/remotes/mine/*' invalid + test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*' test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*' -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request: Passing a number as an option to git tags for displaying latest tags
On Thu, Jul 23, 2015 at 2:39 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: While not quite being intended for that purpose, git log --oneline --decorate --simplify-by-decoration [-n] --tags (or with a custom format instead of --oneline --decorate) may come close to what you want.[*] Michael [*] As Linus once described it (iirc): oooh, evil. I like it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Yep, that's pretty much how a build system I've had to use does it. Sadly, this is quite slow, and I'm not sure if doing it built into the tag via for-each-ref would be faster? I mean obviously having to look at each commit is slower than just the tag name, but it might be faster than parsing through the log process? Though the log output has the advantage that it only shows you tags on a given branch. Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unexplained behavior/issue with git archive?
John Keeping j...@keeping.me.uk writes: With a small number of items, there should only be one output line, but if xargs invokes the command multiple times there will be multiple lines. For example (using -L2 to force a maximum of two arguments per invocation): $ printf '%s\n' a b c | xargs -d'\n' echo | wc -l 1 $ printf '%s\n' a b c | xargs -d'\n' -L2 echo | wc -l 2 Yup, I think this thread is mistitled; it looks like an unexpected behaviour with xargs. Or common pitfalls with xargs, perhaps. Now, what would be a reasonable workaround. To work around command line length limits (not necessarily for xargs, but the exact same issue would arise if you are trying to specify too many pathspecs on the command line), many of our commands take paths from their standard input. Would it be reasonable to teach git archive to also do so? Or would it make sense to teach git archive -o a new mode to append to an existing archive, so that repeated invocations of git archive via such a use of xargs would create in the first invocation and then keep appending to the same archive in the subsequent invocations? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
Karsten Blees karsten.bl...@gmail.com writes: I'd like to add that this is not a git-specific problem: resetting mtime on purpose will fool lots of programs, including backup software, file synchronization tools (rsync, xcopy /D), build systems (make), and web servers / proxies (If-Modified-Since requests). So you would typically reset mtime if you *want* programs to ignore the changes. Yup. Nicely phrased. When you run a wholesale rewrite of many files, often you find that some (or many) of the files did not have to be modified. E.g. perl -i -e 's/old/new/' * may want to touch all files, but the files that did not have string 'old' in them would have the same contents as before. In such a case, you can avoid unnecessary reinspection of contents (e.g. recompilation) by many tools that pay attention to mtime to see if contents changed by reverting mtime to the original for files that did not change. Git also pays attention to fields other than mtime, so after perl -i -e 's/old/ancient/' * and reverting mtime even for ones that got changed, we should notice the changes. But you are correct that such an abuse of touch will break many other tools. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request: Passing a number as an option to git tags for displaying latest tags
Jacob Keller jacob.kel...@gmail.com writes: On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano gits...@pobox.com wrote: Jacob Keller jacob.kel...@gmail.com writes: Yep, that's pretty much how a build system I've had to use does it. Sadly, this is quite slow, and I'm not sure if doing it built into the tag via for-each-ref would be faster? Is the description in git for-each-ref --help somehow unreadable? ... If you only need the name of the ref, you can use a lot simpler format string, e.g. git for-each-ref --count=3 --sort='-*authordate' \ --format='%(refname:short)' refs/tags git for-each-ref --count=3 --sort='-taggerdate' \ --format='%(refname:short)' refs/tags That's significantly better than what this system does, but sadly the team that owns it doesn't exactly understand git. Pretty sure they tend to just use whatever scriptlet they got working, which happens to be based on log... I've tried to help them, but generally hasn't been a successful relationship there. If your build people refuse to switch from an unreliable way of parsing log output that is not meant for machine consumption, then it wouldn't make any difference what the answer to your I'm not sure if doing it built into ... be faster? X-. By the way, I was referring to that question, pointing out that you do not have be wondering. It is already there, and as I said a few messages ago already in this thread, the cross-pollination among for-each-ref, branch -l and tag -l is happening as part of this year's GSoC program. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
On Thu, Jul 23, 2015 at 11:53:37AM +0200, Michael J Gruber wrote: That reminds me of my attempt to add those categories to the man pages of each command (rather than just to that of git) so that users know where they landed. It died off, though: I preferred just specifying the category (maybe with a long form), others including the whole explanation of the category (which I thought would be too much text; we have the glossary for that). Would something like that help? Maybe category plus optionally pointer to a related command in the other category. Maybe a SCRIPTING section at the end of the page? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
Jeff King p...@peff.net writes: I am sympathetic, though. There are some things that git-log can do that rev-list cannot, so people end up using it in scripts. I think you can avoid it with a rev-list | diff-tree pipeline, though I'm not 100% sure if that covers all cases. But I would much rather see a solution along the lines of making the plumbing cover more cases, rather than trying to make the porcelain behave in a script. Very well said. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] receive-pack: crash when checking with non-exist HEAD
Jeff King p...@peff.net writes: On Wed, Jul 22, 2015 at 01:30:00PM -0700, Junio C Hamano wrote: For example, in order to git commit from such a state to create the root commit on that branch, existing unrelated branches whose names collide with the branch must be removed, which would mean one of two things, either (1) you end up losing many unrelated work, or (2) the command refuses to work, not letting you to record the commit. Neither is satisfactory, but we seem to choose (2), which is at least the safer of the two: $ git checkout master $ git checkout --orphan master/1 $ git commit -m foo fatal: cannot lock ref 'HEAD': 'refs/heads/master' exists; cannot create 'refs/heads/master/1' Yeah, that seems sensible. I think the way out for the user here would presumably be: git symbolic-ref HEAD refs/heads/something-else though of course they could also rename the other ref. I would have expected you to say git checkout --orphan something-else which should work and would be more intuitive ;-) Right. You'd have to teach the is_refname_available() check to always check what HEAD points to, and consider it as taken, even if the ref itself doesn't exist. But what about other symbolic refs? The refs/remotes/origin/HEAD symref may point to refs/remotes/origin/master even though refs/remotes/origin/master/1 exists. I doubt that will cause real problems in practice, but it points out that special cases like the value of HEAD is magic and reserved will later end up being insufficient as the code is extended. Yes, we do not have a handy cache of all symrefs, and it is dubious if this issue is grave enough to warrant adding one. I think I'd be willing to simply punt on the whole thing as being too rare to come up in practice. I tend to agree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request: Passing a number as an option to git tags for displaying latest tags
Jacob Keller jacob.kel...@gmail.com writes: Yep, that's pretty much how a build system I've had to use does it. Sadly, this is quite slow, and I'm not sure if doing it built into the tag via for-each-ref would be faster? Is the description in git for-each-ref --help somehow unreadable? An example directly producing formatted text. Show the most recent 3 tagged commits: #!/bin/sh git for-each-ref --count=3 --sort='-*authordate' \ --format='From: %(*authorname) %(*authoremail) Subject: %(*subject) Date: %(*authordate) Ref: %(*refname) %(*body) ' 'refs/tags' If you only need the name of the ref, you can use a lot simpler format string, e.g. git for-each-ref --count=3 --sort='-*authordate' \ --format='%(refname:short)' refs/tags git for-each-ref --count=3 --sort='-taggerdate' \ --format='%(refname:short)' refs/tags -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request: Passing a number as an option to git tags for displaying latest tags
On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano gits...@pobox.com wrote: Jacob Keller jacob.kel...@gmail.com writes: Yep, that's pretty much how a build system I've had to use does it. Sadly, this is quite slow, and I'm not sure if doing it built into the tag via for-each-ref would be faster? Is the description in git for-each-ref --help somehow unreadable? An example directly producing formatted text. Show the most recent 3 tagged commits: #!/bin/sh git for-each-ref --count=3 --sort='-*authordate' \ --format='From: %(*authorname) %(*authoremail) Subject: %(*subject) Date: %(*authordate) Ref: %(*refname) %(*body) ' 'refs/tags' If you only need the name of the ref, you can use a lot simpler format string, e.g. git for-each-ref --count=3 --sort='-*authordate' \ --format='%(refname:short)' refs/tags git for-each-ref --count=3 --sort='-taggerdate' \ --format='%(refname:short)' refs/tags That's significantly better than what this system does, but sadly the team that owns it doesn't exactly understand git. Pretty sure they tend to just use whatever scriptlet they got working, which happens to be based on log... I've tried to help them, but generally hasn't been a successful relationship there. Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
On Thu, Jul 23, 2015 at 9:44 AM, Junio C Hamano gits...@pobox.com wrote: Jacob Keller jacob.kel...@gmail.com writes: By the way, have you run test suite before sending this (or any previous round of this) patch? This seems to break t5511-refspec.sh for me. Looks like another location I forgot to update. I can send a re-spin if you need with the following diff. Basically looks like the tests just didn't get updated to count the new behavior is valid. Yeah, basically looks like an untested patch was sent and nobody noticed during earlier rounds, even the patch was rerolled a few times, before I finally took it to 'pu' to take a look. A typical slow summer moment---people rightfully find it is more important to have fun themselves than to help polishing others' patches ;-). I think what happened, is that I ran some tests when the patch was configurable and I had modified the one set of tests to try with the option enabled, but it didn't fail in the t5511-refspec.sh since this series of tests didn't enable the new option. Then, I never re-tested again (OOPS!) when I removed the optional portion. Will squash the changes; no need to resend (unless people discover other issues; let's hope that I wouldn't be the one to do so ;-). Thanks. Thank you! :) Regards, Jake diff --git i/t/t5511-refspec.sh w/t/t5511-refspec.sh index de6db86ccff0..7bfca7962d41 100755 --- i/t/t5511-refspec.sh +++ w/t/t5511-refspec.sh @@ -71,11 +71,11 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me' test_refspec push ':refs/remotes/frotz/delete me' invalid test_refspec fetch ':refs/remotes/frotz/HEAD to me'invalid -test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid -test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid +test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' +test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' -test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid -test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid +test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' +test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
On Thu, Jul 23, 2015 at 09:06:01AM +0200, Sebastian Schuberth wrote: My use-case (also see [1]) is that I wanted to checked whether some given commits change nothing but whitespace. So I did if git diff-tree --quiet --ignore-space-change $commit; then echo $commit only changes whitespace. fi just to see those SHA1s being printed to the console. I probably could instead do if git diff-tree --exit-code --ignore-space-change $commit /dev/null 21; then echo $commit only changes whitespace. fi but that defeats the purpose of having --quiet in the first place. I have not been following the thread closely, but I do not recall seeing anyone mention that the reason for the sha1-output is handing only a single commit-ish to diff-tree is what puts it into its log-like mode. Actually asking for a two-endpoint tree diff: git diff-tree --quiet --ignore-space-change $commit^ $commit will do what you want. I know that does not necessarily help the greater issue of what diff-tree is doing is confusing, but perhaps that sheds some light at least on why it is doing what it is doing. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 9/9] tag.c: implement '--merged' and '--no-merged' options
On Thu, Jul 23, 2015 at 1:10 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: +--merged [commit]:: + Only list tags whose tips are reachable from the + specified commit (HEAD if not specified). + +--no-merged [commit]:: + Only list tags whose tips are not reachable from the + specified commit (HEAD if not specified). You may want to spell it `HEAD` (with backticks). Will do! -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
Sebastian Schuberth sschube...@gmail.com writes: Well, from a user's perspective it does not matter which part of the internal implementation of diff-tree is responsible for printing that single line,... That is not internal implementation, but logically separate parts. View it more like 'git show -s' does squelch the diff part but does not squelch the log output. After all, a single commit form of 'diff-tree' is a degenerate use case of feeding a single commit to 'diff-tree --stdin' from its standard input, which is a rough plumbing-level equivalent of 'show'. Documenting the behaviour correctly is the best thing you could do at this point, as this is one of the oldest part of the system that existing scripts would rely on. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
Jacob Keller jacob.kel...@gmail.com writes: By the way, have you run test suite before sending this (or any previous round of this) patch? This seems to break t5511-refspec.sh for me. Looks like another location I forgot to update. I can send a re-spin if you need with the following diff. Basically looks like the tests just didn't get updated to count the new behavior is valid. Yeah, basically looks like an untested patch was sent and nobody noticed during earlier rounds, even the patch was rerolled a few times, before I finally took it to 'pu' to take a look. A typical slow summer moment---people rightfully find it is more important to have fun themselves than to help polishing others' patches ;-). Will squash the changes; no need to resend (unless people discover other issues; let's hope that I wouldn't be the one to do so ;-). Thanks. diff --git i/t/t5511-refspec.sh w/t/t5511-refspec.sh index de6db86ccff0..7bfca7962d41 100755 --- i/t/t5511-refspec.sh +++ w/t/t5511-refspec.sh @@ -71,11 +71,11 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me' test_refspec push ':refs/remotes/frotz/delete me' invalid test_refspec fetch ':refs/remotes/frotz/HEAD to me'invalid -test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid -test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid +test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' +test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' -test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid -test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid +test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' +test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
Junio C Hamano gits...@pobox.com writes: Sebastian Schuberth sschube...@gmail.com writes: Well, from a user's perspective it does not matter which part of the internal implementation of diff-tree is responsible for printing that single line,... That is not internal implementation, but logically separate parts. View it more like 'git show -s' does squelch the diff part but does not squelch the log output. After all, a single commit form of 'diff-tree' is a degenerate use case of feeding a single commit to 'diff-tree --stdin' from its standard input, which is a rough plumbing-level equivalent of 'show'. Documenting the behaviour correctly is the best thing you could do at this point, as this is one of the oldest part of the system that existing scripts would rely on. Having said that. Existing scripts by definition would not be using a new option you will invent that used not to be a valid one. So that would be one way that you can shorten your script without breaking other people. If we were living in an ideal world equipped with a time machine, I would redesign git diff-tree $commit so that it does not show the commit object name in its output at all, with or without --quiet. In git rev-list ... | git diff-tree --stdin output, the commit object name is absolutely necessary, with or without --quiet, as it serves as the sign that the output switched to talk about a different commit. But the case that feeds a single commit to the command, used as a poor-man's git show $commit, does not need one---the caller knows exactly which commit the output is about. It is an unfortunate historical accident that a single commit usage is defined to be a degenerate case of feeding a sequence of commits to the command and the length of the sequence happens to be one. But we do not live in an ideal world. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
On Wed, Jul 22, 2015 at 11:53 PM, Jeff King p...@peff.net wrote: man git already has such a list (which is generated from the annotations in command-list.txt). But I agree that it would probably be helpful to point people directly from git log to git rev-list and vice versa. -Peff That's good. I just know that I've had many a co-worker complain because the man page felt too technical because they accidentally found their way into a plumbing section. If I heard a specific case of confusion again in the future I'll try to work up a patch for it. Regards, Jake -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
On Wed, Jul 22, 2015 at 10:32 PM, Junio C Hamano gits...@pobox.com wrote: --quite is documented to Disable all output of the program. Yet calling diff-tree with a single commit like $ git diff-tree --quiet c925fe2 was logging c925fe23684455735c3bb1903803643a24a58d8f At this point, unfortunately I think we need to call that a documentation bug. The output it refers to is output from the diff portion, not the poor-man's log portion, of the program, where diff-tree was the workhorse behind scripted git log that gave the commit object name as the preamble for each commit it shows information about. Well, from a user's perspective it does not matter which part of the internal implementation of diff-tree is responsible for printing that single line, a user would just expect --quiet to really mean quiet. As for almost any bug, we could turn it into a feature by fixing the docs and claiming it's documented behavior. To me the question simply is whether it makes sense for --quiet to not be quiet, and I think it does not make sense. If you run diff-tree this way there is no added value in the given output. My use-case (also see [1]) is that I wanted to checked whether some given commits change nothing but whitespace. So I did if git diff-tree --quiet --ignore-space-change $commit; then echo $commit only changes whitespace. fi just to see those SHA1s being printed to the console. I probably could instead do if git diff-tree --exit-code --ignore-space-change $commit /dev/null 21; then echo $commit only changes whitespace. fi but that defeats the purpose of having --quiet in the first place. [1] http://article.gmane.org/gmane.comp.version-control.git/273975 -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bash __git_ps1 line wrapping issue on OSX
I have sourced git-prompt.sh (copied from
https://github.com/git/git/tree/master/contrib/completion) and included it
in my .bashrc as follows:
GIT_PS1_SHOWDIRTYSTATE=true;
GIT_PS1_SHOWUPSTREAM=verbose;
GIT_PS1_SHOWCOLORHINTS=true;
PROMPT_COMMAND='__git_ps1 # \u@\h:\w \$ ';
Under CentOS etc. this works fine. On OSX however, when dealing with a
nested folder structure that causes line wrapping, the formatting of the bit
where you type goes do-lally-tap. Character spacing is wrong (like each
character is tab separated) and once it hits the end of the line it starts
to overwrite itself (but only the last character). There is a screen shot
of the issue on the StackOverflow question I've asked about this at
http://stackoverflow.com/questions/31561969/bash-git-ps1-line-wrapping-issue-on-osx.
The code that __git_ps1 has generated for PS1 is:
# \u@\h:\w (\[\e[32m\]${__git_ps1_branch_name}\[\e[0m\] \[\e[31m\]*\[\e[0m\]
u=) $
Has anyone experienced this and / or could suggest a solution?
If I comment out the GIT_PS1_SHOWCOLORHINTS directive it works, albeit
without the colour highlighting, so I'm guessing there is something amiss in
the control sequences somewhere.
Thanks,
Adam M.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Git doesn't detect change, if file modification time is restored to original one
I wrote a search replace perl script, which recursively searches files and replaces text in them. After replace, it restores original modification time (mtime) of file. Interesting, that git status doesn't show replaced changes, if the mtime is same as original. Is there a way to force git status to show changes, even if the file dates are the same? I tried to set core to: trustctime = false checkStat = minimal Unfortunately the change is still not detected :( It seems isn't a way to force fallback to file checking and completely ignore file modification date :( Any idea? Thanks, Konrad Lorinczi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
On Wed, Jul 22, 2015 at 11:32:49PM -0700, Jacob Keller wrote: Agreed. Fix the plumbing instead and document how/why to use it instead of the porcelain. We might do better to help clearly document which commands are porcelain and which are plumbing maybe by referencing which plumbings to use in place of various porcelain commands. I know, for example, that git status already does this. man git already has such a list (which is generated from the annotations in command-list.txt). But I agree that it would probably be helpful to point people directly from git log to git rev-list and vice versa. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
Jacob Keller venit, vidit, dixit 23.07.2015 08:55: On Wed, Jul 22, 2015 at 11:53 PM, Jeff King p...@peff.net wrote: man git already has such a list (which is generated from the annotations in command-list.txt). But I agree that it would probably be helpful to point people directly from git log to git rev-list and vice versa. -Peff That's good. I just know that I've had many a co-worker complain because the man page felt too technical because they accidentally found their way into a plumbing section. If I heard a specific case of confusion again in the future I'll try to work up a patch for it. Regards, Jake That reminds me of my attempt to add those categories to the man pages of each command (rather than just to that of git) so that users know where they landed. It died off, though: I preferred just specifying the category (maybe with a long form), others including the whole explanation of the category (which I thought would be too much text; we have the glossary for that). Would something like that help? Maybe category plus optionally pointer to a related command in the other category. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git doesn't detect change, if file modification time is restored to original one
Based on [1] I found some solutions which makes the changed files appear again as changed: a) touch -m --date=01/01/1980 .git/index So it is a touch, but only a single one, instead of touching all the files in the work dir. b) git read-tree HEAD Also working well. I accept these solutions as workarounds, but the real solution would be: Dev suggestions: 1) Add a --force-reread option to git status, so user can force reread tree. git status --force-reread 2) Add status.force-reread (true or false) option to .git/config so user can set this variable permanently for a repo. status.force-reread = false (should be default) Could be possible to implement 1) and 2) features to next git release? Thanks, Konrad Lorinczi [1] https://github.com/msysgit/git/issues/312 2015-07-23 9:58 GMT+02:00 Sebastian Schuberth sschube...@gmail.com: On 7/23/2015 9:29, Konrád Lőrinczi wrote: Interesting, that git status doesn't show replaced changes, if the mtime is same as original. See the somewhat related FAQ entry at [1] and also the lengthy discussion at [2] about a similar issue. That said, deleting the .git/index file should make these files appear as modified. [1] https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F [2] https://github.com/msysgit/git/issues/312 Regards, Sebastian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request: Passing a number as an option to git tags for displaying latest tags
Junio C Hamano venit, vidit, dixit 22.07.2015 21:20: Junio C Hamano gits...@pobox.com writes: The former, sort by time, is interesting, but you need to define what to do with various corner cases. For example, some people may have one or more of the following desires: * My project did not use tags for a long time, and started using it recently starting from v1.1.0. The first release only said Frotz version 1.0.0 in its commit log message. I retroactively did git tag -s -m 'Frotz 1.1.0' v1.1.0 on that commit. Obviously, I meant git tag -s -m 'Frotz 1.0.0' v1.0.0 here. In such a case, it is likely that I would want the sorting done based on the committer date on the underlying commit, not the tag's tagger date. * When a bug is found, it is customary in my project to add a break-something tag to the commit that introduces the bug (and fix-something tag to the commit that fixes it). When I want to find recently discovered breakages, I want the tags whose names match break-* sorted by tagger dates, not the underlying commit's committer dates. Another use case may be one in which older tags are interesting. In other words, you need to be able to sort in reverse, too. The necessary ordering machinery to do the above already exists in for-each-ref. There is a GSoC project that works to unify various features spread across for-each-ref, branch -l and tag -l and make them available to all of the three. And the above is still true even with reverse-order use case. While not quite being intended for that purpose, git log --oneline --decorate --simplify-by-decoration [-n] --tags (or with a custom format instead of --oneline --decorate) may come close to what you want.[*] Michael [*] As Linus once described it (iirc): oooh, evil. I like it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
