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)
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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 @@
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
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 +--
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
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
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
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 +-
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
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
+++
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
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 gits...@pobox.com
Signed-off-by: Eric
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 ++--
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
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
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:
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
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
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
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
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
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
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.,
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
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
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
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
---
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
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.[*]
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
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
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
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
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
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
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?
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
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
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
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
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
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.
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
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
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,
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.
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
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
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
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
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
68 matches
Mail list logo
