On Thu, Jul 23, 2015 at 10:02:27PM +0200, Sebastian Schuberth wrote:
> On Thu, Jul 23, 2015 at 8:08 PM, Jeff King 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 kno
On Thu, Jul 23, 2015 at 3:46 PM, Junio C Hamano wrote:
> Jeff King 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 h
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
---
builtin/merge.c | 3 +--
builtin/reset.c | 6 ++
Signed-off-by: David Turner
---
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-appl
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
---
git-bisect.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index ea63223..82635
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
---
bisect.c | 35 +++
1 file changed, 7 insertions(+), 28 deletions(-)
diff --git a/bisect.c b/bisect.c
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
---
bisect.c | 2 +-
refs.c| 2 ++
t/
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
---
builtin/am.c | 6 +++---
contrib/examples/git-am.sh | 4 ++--
git-rebase--interactive.sh | 2 +-
git-rebase.sh | 2 +
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 slighl
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 pseudo
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 cvs2sv
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
-
Signed-off-by: Eric Sunshine
---
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.t
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 patc
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 Sunsh
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.
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
Signed-off-by: Eric Sunshine
---
Referenc
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
---
Documentation/git-tools.txt | 134 ++--
1 file changed, 67 ins
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
Signed-off-by: Eric Sunshine
---
Referenc
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
Eric Sunshine writes:
> On Mon, Jul 20, 2015 at 11:31 AM, Michael Haggerty
> 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
"Keller, Jacob E" 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 "re
On Thu, 2015-07-23 at 15:12 -0700, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > On Wed, Jul 22, 2015 at 5:05 PM, Jacob Keller <
> > jacob.e.kel...@intel.com> wrote:
> > > From: Jacob Keller
> > >
> > > Modify logic of check_refname_component and add a new disposition
> > > regarding "*".
On Mon, Jul 20, 2015 at 11:31 AM, Michael Haggerty 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 chaf
Jeff King 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
On Wed, Jul 22, 2015 at 6:23 PM, Jeff King 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
> g
Eric Sunshine writes:
> On Wed, Jul 22, 2015 at 5:05 PM, Jacob Keller
> wrote:
>> From: Jacob Keller
>>
>> 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 p
On Wed, Jul 22, 2015 at 5:05 PM, Jacob Keller wrote:
> From: Jacob Keller
>
> 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
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 ]
".
Signed-off-by: Eric Sunshine
---
This is RFC since this is my first foray into the Git completion script,
and
Sebastian Schuberth writes:
> On Thu, Jul 23, 2015 at 9:39 PM, Junio C Hamano 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 ;-).
>
> Ex
On Thu, Jul 23, 2015 at 9:39 PM, Junio C Hamano 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 so
On Thu, Jul 23, 2015 at 7:06 PM, Junio C Hamano 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 shorteni
On Thu, Jul 23, 2015 at 8:08 PM, Jeff King 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,
Jeff King 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 di
Jacob Keller writes:
> On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano wrote:
>> Jacob Keller 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?
On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano wrote:
> Jacob Keller 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
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 whit
On Thu, Jul 23, 2015 at 9:44 AM, Junio C Hamano wrote:
> Jacob Keller 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
Jacob Keller 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 direc
Jeff King 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
>>
Jeff King 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
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
Karsten Blees 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).
>
>
On Thu, Jul 23, 2015 at 2:39 AM, Michael J Gruber
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
>
>
John Keeping 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
On Thu, Jul 23, 2015 at 10:13 AM, Junio C Hamano 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 mul
Junio C Hamano 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
Junio C Hamano writes:
> Sebastian Schuberth 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".
Jacob Keller 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 look
Sebastian Schuberth 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' do
On Thu, Jul 23, 2015 at 1:10 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> +--merged []::
>> + Only list tags whose tips are reachable from the
>> + specified commit (HEAD if not specified).
>> +
>> +--no-merged []::
>> + Only list tags whose tips are not reachable from the
>>
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"
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.s
Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov:
> On Thu, 23 Jul 2015 11:14:11 +0200
> Konrád Lőrinczi 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
On Thu, 23 Jul 2015 11:14:11 +0200
Konrád Lőrinczi 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
On Thu, Jul 23, 2015 at 12:14 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> + strtoul_ui(valp, 10, &ref->align_value);
>> + if (ref->align_value < 1)
>> + die(_("Value should be greater than zero"));
>
> You're not checkin
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
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 unsubsc
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
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
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 m
Jacob Keller venit, vidit, dixit 23.07.2015 08:55:
> On Wed, Jul 22, 2015 at 11:53 PM, Jeff King 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
Junio C Hamano venit, vidit, dixit 22.07.2015 21:20:
> Junio C Hamano 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 us
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 wor
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 et
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
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 stat
On Wed, Jul 22, 2015 at 10:32 PM, Junio C Hamano 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, u
68 matches
Mail list logo
