* Re: [BUG] rebase --interactive silently overwrites ignored files
@ 2019-05-05 4:02 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2019-05-05 4:02 UTC (permalink / raw)
To: Phillip Wood
Cc: wh, phillip.wood, git, Johannes Schindelin,
Nguyễn Thái Ngọc Duy
Phillip Wood <phillip.wood123@gmail.com> writes:
> I've had a look at the rebase -i code and I think it only overwrites
> ignored files when it is fast-forwarding. This matches what merge does
> when fast-forwarding but I'm not convinced either of them should be
> doing this by default (I think checkout doing it is probably asking
> for trouble)...
> I'll put a patch together to fix rebase -i, I'd like to see the
> defaults for merge and checkout changed but I'm not sure that would be
> popular.
I suspect that such a change in behaviour for "rebase -i" is not a
fix but a regression. Shouldn't it be consistent with checkout and
merge?
> It does seem like surprising behavior though when most
> operations try to preserve untracked files.
Are you conflating untracked and ignored?
Because we haven't adopted 'precious' (or whatever the final name
would be), which is "ignored but not expendable", ignored files are
by definition "ignored and expendable". When checkout (and merge
that is its more general form) needs to match the working tree to
the index contents and an ingored file is in the way, it should
overwrite it.
Until we introduce "ignored but not expendable" class, that is.
^ permalink raw reply [relevance 4%]
* auto gc again
@ 2008-03-18 18:01 4% Jens Axboe
0 siblings, 0 replies; 200+ results
From: Jens Axboe @ 2008-03-18 18:01 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
Hi,
Could we please PLEASE kill this auto gc thing? I've complained about
this in the past and disabled it through the gc.auto config entry,
however now git seems to be happily auto running gc even with gc.auto=0.
So there's probably some new magic I need to know.
But the new magic is really beside the point. Doing this 'for you' is
extremely annoying behaviour. I often work on my notebook, so disk is
both slow and battery is precious. I DON'T want gc to run automatically,
EVER. Not on repos I have had going for ages, not on ones I just cloned.
Please bury this silly policy and replace it with a printf() telling me
that I may increase my performance by running git gc. Don't just do it.
git does not know better.
--
Jens Axboe
^ permalink raw reply [relevance 4%]
* Re: [PATCH 6/8] checkout: add --cached option
@ 2019-02-19 22:24 4% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2019-02-19 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Duy Nguyen, Thomas Gummerer, Git Mailing List
On Tue, Feb 19, 2019 at 11:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > Overall this looks good, but there's just one part that confuses me.
> > Here you seem to suggest that if you pass --source but neither --index
> > or --worktree that both the index and working tree will be written to.
> > Why are "restored" changes considered ready for commit? That seems
> > confusing to me (and was one of the bugs of checkout, IMO). See also
> > second half of https://public-inbox.org/git/xmqq1s6yezk3.fsf@gitster-ct.c.googlers.com/
>
> As long as worktree-only mode does not lose track of a
> previously-untracked path in the index (perhaps use the i-t-a bit),
> I do not have a strong objection against making the worktree-only
> mode the default.
Could you unpack that for me a bit? My assumption is that
worktree-only mode doesn't touch the index (other than maybe reading
from it), and treating the index as read-only means by definition it
can't lose anything from there -- but then you mentioned using the
intent-to-add bit, and I feel like I'm missing an important puzzle
piece somewhere. Trying to make sense of it, I'm wondering if you are
objecting to using overlay mode in general, or are trying to connect
this to the new "precious" concept being advanced, or if there's
something else you are considering here.
^ permalink raw reply [relevance 4%]
* [PATCH] t7701: make annotated tag unreachable
@ 2023-06-21 10:21 4% Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2023-06-21 10:21 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In 4dc16e2cb0 (gc: introduce `gc.recentObjectsHook`, 2023-06-07), we
added tests to ensure that prune-able (i.e. unreachable and with mtime
older than the cutoff) objects which are marked as recent via the new
`gc.recentObjectsHook` configuration are unpacked as loose with
`--unpack-unreachable`.
In that test, we also ensure that objects which are reachable from other
unreachable objects which were *not* pruned are kept as well, regardless
of their mtimes. For this, we use an annotated tag pointing at a blob
($obj2) which would otherwise be pruned.
But after pruning, that object is kept around for two reasons. One, the
tag object's mtime wasn't adjusted to be beyond the 1-hour cutoff, so it
would be kept as due to its recency regardless. The other reason is
because the tag itself is reachable.
Use mktag to write the tag object directly without pointing a reference
at it, and adjust the mtime of the tag object to be older than the
cutoff to ensure that our `gc.recentObjectsHook` configuration is
working as intended.
Noticed-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
Peff pointed this out to me after the gc.recentObjectsHook stuff was in
'next', but this should go on top. This patch is based off of the tip of
"tb/gc-recent-object-hook".
t/t7701-repack-unpack-unreachable.sh | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index ba428c18a8..ceb4e805d2 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -126,8 +126,19 @@ test_expect_success 'gc.recentObjectsHook' '
git cat-file -p $obj2 &&
git cat-file -p $obj3 &&
+ # make an unreachable annotated tag object to ensure we rescue objects
+ # which are reachable from non-pruned unreachable objects
git tag -a -m tag obj2-tag $obj2 &&
- obj2_tag="$(git rev-parse obj2-tag)" &&
+ obj2_tag="$(git mktag <<-EOF
+ object $obj2
+ type blob
+ tag obj2-tag
+ tagger T A Gger <tagger@example.com> 1234567890 -0000
+ EOF
+ )" &&
+
+ obj2_tag_pack="$(echo $obj2_tag | git pack-objects .git/objects/pack/pack)" &&
+ git prune-packed &&
write_script precious-objects <<-EOF &&
echo $obj2_tag
@@ -136,6 +147,7 @@ test_expect_success 'gc.recentObjectsHook' '
test-tool chmtime =-86400 .git/objects/pack/pack-$pack2.pack &&
test-tool chmtime =-86400 .git/objects/pack/pack-$pack3.pack &&
+ test-tool chmtime =-86400 .git/objects/pack/pack-$obj2_tag_pack.pack &&
git repack -A -d --unpack-unreachable=1.hour.ago &&
git cat-file -p $obj1 &&
--
2.40.1.478.g4dc16e2cb0
^ permalink raw reply related [relevance 4%]
* [PATCH v4 3/6] t1302: make tests more robust with new extensions
@ 2024-01-29 11:07 4% ` Patrick Steinhardt
0 siblings, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-01-29 11:07 UTC (permalink / raw)
To: git; +Cc: Taylor Blau, Eric Sunshine, Toon Claes, Christian Couder,
Justin Tobler
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
In t1302 we exercise logic around "core.repositoryFormatVersion" and
extensions. These tests are not particularly robust against extensions
like the newly introduced "refStorage" extension as we tend to clobber
the repository's config file. We thus overwrite any extensions that were
set, which may render the repository inaccessible in case it has to be
accessed with a non-default ref storage.
Refactor the tests to be more robust:
- Check the DEFAULT_REPO_FORMAT prereq to determine the expected
repository format version. This helps to ensure that we only need to
update the prereq in a central place when new extensions are added.
Furthermore, this allows us to stop seeding the now-unneeded object
ID cache that was only used to figure out the repository version.
- Use a separate repository to rewrite ".git/config" to test
combinations of the repository format version and extensions. This
ensures that we don't break the main test repository. While we could
rewrite these tests to not overwrite preexisting extensions, it
feels cleaner like this so that we can test extensions standalone
without interference from the environment.
- Do not rewrite ".git/config" when exercising the "preciousObjects"
extension.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/t1302-repo-version.sh | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index 179474fa65..42caa0d297 100755
--- a/t/t1302-repo-version.sh
+++ b/t/t1302-repo-version.sh
@@ -9,10 +9,6 @@ TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
test_expect_success 'setup' '
- test_oid_cache <<-\EOF &&
- version sha1:0
- version sha256:1
- EOF
cat >test.patch <<-\EOF &&
diff --git a/test.txt b/test.txt
new file mode 100644
@@ -28,7 +24,12 @@ test_expect_success 'setup' '
'
test_expect_success 'gitdir selection on normal repos' '
- test_oid version >expect &&
+ if test_have_prereq DEFAULT_REPO_FORMAT
+ then
+ echo 0
+ else
+ echo 1
+ fi >expect &&
git config core.repositoryformatversion >actual &&
git -C test config core.repositoryformatversion >actual2 &&
test_cmp expect actual &&
@@ -79,8 +80,13 @@ mkconfig () {
while read outcome version extensions; do
test_expect_success "$outcome version=$version $extensions" "
- mkconfig $version $extensions >.git/config &&
- check_${outcome}
+ test_when_finished 'rm -rf extensions' &&
+ git init extensions &&
+ (
+ cd extensions &&
+ mkconfig $version $extensions >.git/config &&
+ check_${outcome}
+ )
"
done <<\EOF
allow 0
@@ -94,7 +100,8 @@ allow 1 noop-v1
EOF
test_expect_success 'precious-objects allowed' '
- mkconfig 1 preciousObjects >.git/config &&
+ git config core.repositoryFormatVersion 1 &&
+ git config extensions.preciousObjects 1 &&
check_allow
'
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [relevance 4%]
* Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.
@ 2007-08-27 11:30 4% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2007-08-27 11:30 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
Hi,
On Mon, 27 Aug 2007, Sam Vilain wrote:
> David Kastrup wrote:
> >> These files which store metadata would be stored in a way that is
> >> "in another dimension" to the project files, despite being a part of
> >> the history. That means that all tools built to deal with regular
> >> files and directories will not be able to merge the changes to the
> >> attributes without special support. I think this is broken.
> >>
> >
> > That presumes that a good way to merge attributes is to use a text
> > file merge algorithm, complete with finding diff context lines in a
> > basically unchanged order.
> >
>
> Yes. Is that not a reasonable assumption, in the absence of anything
> more enlightened?
Umm.
It is not about _text_ file merge algorithms, but algorithms _outside of
git_!
If you tuck the stuff away in some obscure database where it is hard to
access, you make it more complicated and time consuming to access the data
than it needs to be to _begin with_.
> >> As far as file properties goes, I still like Linus' idea of making
> >> these files which are accessed by treating the file as a directory
> >> (eg filename.txt/ACL, filename.txt/mime-type), and that approach
> >> could be represented in git well.
> >
> > Well, at least _some_ interesting Reiser4 idea resurfaces.
>
> That was in there too? Man that Reiser4 manifesto read like the Naked
> Lunch.
It is funny. No, I mean really funny. People criticise Reiser4, and only
preciously few actually have ideas as good as in Reiser4. Yes, Reiser4
was not developed as openly as it should have been. Yes, Hans was not the
most diplomatic poster ever, on lkml. No, even the stupid ideas in
Reiser4 are not half as stupid as mistaking the working tree for a place
where only _text_ files reside.
Ciao,
Dscho
^ permalink raw reply [relevance 4%]
* [PATCH v3 3/6] t1302: make tests more robust with new extensions
@ 2024-01-24 8:45 4% ` Patrick Steinhardt
0 siblings, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-01-24 8:45 UTC (permalink / raw)
To: git; +Cc: Taylor Blau, Eric Sunshine, Toon Claes, Christian Couder,
Justin Tobler
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
In t1302 we exercise logic around "core.repositoryFormatVersion" and
extensions. These tests are not particularly robust against extensions
like the newly introduced "refStorage" extension as we tend to clobber
the repository's config file. We thus overwrite any extensions that were
set, which may render the repository inaccessible in case it has to be
accessed with a non-default ref storage.
Refactor the tests to be more robust:
- Check the DEFAULT_REPO_FORMAT prereq to determine the expected
repository format version. This helps to ensure that we only need to
update the prereq in a central place when new extensions are added.
Furthermore, this allows us to stop seeding the now-unneeded object
ID cache that was only used to figure out the repository version.
- Use a separate repository to rewrite ".git/config" to test
combinations of the repository format version and extensions. This
ensures that we don't break the main test repository. While we could
rewrite these tests to not overwrite preexisting extensions, it
feels cleaner like this so that we can test extensions standalone
without interference from the environment.
- Do not rewrite ".git/config" when exercising the "preciousObjects"
extension.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/t1302-repo-version.sh | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index 179474fa65..42caa0d297 100755
--- a/t/t1302-repo-version.sh
+++ b/t/t1302-repo-version.sh
@@ -9,10 +9,6 @@ TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
test_expect_success 'setup' '
- test_oid_cache <<-\EOF &&
- version sha1:0
- version sha256:1
- EOF
cat >test.patch <<-\EOF &&
diff --git a/test.txt b/test.txt
new file mode 100644
@@ -28,7 +24,12 @@ test_expect_success 'setup' '
'
test_expect_success 'gitdir selection on normal repos' '
- test_oid version >expect &&
+ if test_have_prereq DEFAULT_REPO_FORMAT
+ then
+ echo 0
+ else
+ echo 1
+ fi >expect &&
git config core.repositoryformatversion >actual &&
git -C test config core.repositoryformatversion >actual2 &&
test_cmp expect actual &&
@@ -79,8 +80,13 @@ mkconfig () {
while read outcome version extensions; do
test_expect_success "$outcome version=$version $extensions" "
- mkconfig $version $extensions >.git/config &&
- check_${outcome}
+ test_when_finished 'rm -rf extensions' &&
+ git init extensions &&
+ (
+ cd extensions &&
+ mkconfig $version $extensions >.git/config &&
+ check_${outcome}
+ )
"
done <<\EOF
allow 0
@@ -94,7 +100,8 @@ allow 1 noop-v1
EOF
test_expect_success 'precious-objects allowed' '
- mkconfig 1 preciousObjects >.git/config &&
+ git config core.repositoryFormatVersion 1 &&
+ git config extensions.preciousObjects 1 &&
check_allow
'
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [relevance 4%]
* Re: [PATCH 0/2] test-lib-functions.sh: keep user's HOME, TERM and SHELL for 'test_pause' and 'debug'
@ 2021-08-19 20:11 4% ` Eric Sunshine
0 siblings, 0 replies; 200+ results
From: Eric Sunshine @ 2021-08-19 20:11 UTC (permalink / raw)
To: Elijah Newren
Cc: Philippe Blain via GitGitGadget, Git List, SZEDER Gábor,
Johannes Schindelin, Jens Lehmann, Philippe Blain
On Thu, Aug 19, 2021 at 4:03 PM Elijah Newren <newren@gmail.com> wrote:
> On Thu, Aug 19, 2021 at 11:10 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > I also find the test_pause() user-experience suboptimal and appreciate
> > the idea of improving it. However, this approach seems fatally flawed.
> > In particular, setting HOME to the user's real home directory could
> > lead to undesirable results. When I'm using test_pause() to debug a
> > problem with a test, I'm not just inspecting the test state, but I
> > quite often interact with the state using the same Git commands as the
> > test itself would use. Hence, it is very common for me to pause the
> > test just before the suspect commands and then run those commands
> > manually (instead of allowing the test script to do so). In such a
> > scenario, HOME must be pointing at the test's home directory, not at
> > my real home directory.
>
> I agree, but I worry that it's not just HOME. I'd think the point of
> test_pause is to let you interact with the repository state while
> getting the same results that the test framework would, and I think
> some tests could be affected by TERM and SHELL too (e.g. perhaps the
> recent issues with COLUMNS). Granted, I suspect far fewer tests would
> be affected by those, but I'm not sure I like the idea of inability to
> reproduce the same issues.
Oh, indeed. I didn't mean to imply that HOME is the only problematic
one; they all are since, as you say, they can impact correctness and
reproducibility of the tests themselves. I called out HOME specially
because of the potential danger involved with pointing it at the
user's real home directory since it could very well lead to clobbering
of precious files and other settings belonging to the user.
^ permalink raw reply [relevance 4%]
* Re: Repacking a repository uses up all available disk space
@ 2016-06-13 0:24 4% ` Duy Nguyen
0 siblings, 0 replies; 200+ results
From: Duy Nguyen @ 2016-06-13 0:24 UTC (permalink / raw)
To: Jeff King; +Cc: Konstantin Ryabitsev, Git Mailing List
On Mon, Jun 13, 2016 at 5:13 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Jun 12, 2016 at 05:54:36PM -0400, Konstantin Ryabitsev wrote:
>
>> > git gc --prune=now
>>
>> You are correct, this solves the problem, however I'm curious. The usual
>> maintenance for these repositories is a regular run of:
>>
>> - git fsck --full
>> - git repack -Adl -b --pack-kept-objects
>> - git pack-refs --all
>> - git prune
>>
>> The reason it's split into repack + prune instead of just gc is because
>> we use alternates to save on disk space and try not to prune repos that
>> are used as alternates by other repos in order to avoid potential
>> corruption.
Isn't this what extensions.preciousObjects is for? It looks like prune
just refuses to run in precious objects mode though, and repack is
skipped by gc, but if that repack command works, maybe we should do
something like that in git-gc?
BTW Jeff, I think we need more documentation for
extensions.preciousObjects. It's only documented in technical/ which
is practically invisible to all users. Maybe
include::repository-version.txt in config.txt, or somewhere close to
alternates?
> [2] It's unclear to me if you're passing any options to git-prune, but
> you may want to pass "--expire" with a short grace period. Without
> any options it prunes every unreachable thing, which can lead to
> races if the repository is actively being used.
>
> At GitHub we actually have a patch to `repack` that keeps all
> objects, reachable or not, in the pack, and use it for all of our
> automated maintenance. Since we don't drop objects at all, we can't
> ever have such a race. Aside from some pathological cases, it wastes
> much less space than you'd expect. We turn the flag off for special
> cases (e.g., somebody has rewound history and wants to expunge a
> sensitive object).
>
> I'm happy to share the "keep everything" patch if you're interested.
Ah ok, I guess this is why we just skip repack. I guess '-Adl -b
--pack-kept-objects' is not enough then.
--
Duy
^ permalink raw reply [relevance 4%]
* Re: [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive
@ 2021-02-11 7:30 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-02-11 7:30 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
Martin von Zweigbergk <martinvonz@google.com> writes:
> Good point. You dropped the bit about the notes (texts) being kept
> alive. I don't know if you did that intentionally are not.
Yes, I did it on purpose, because it is just one of the things that
can be reached from refs/, but we shouldn't write our document for
those like me, who know what notes and other things in Git are.
> I initially
> thought that we should keep that bit, but it's probably not actually
> very useful information. Users probably don't have large amounts of
> information stored in notes, so they probably don't care whether notes
> text is kept, especially since there's no good way of pruning the
> notes.
I am not sure if I agree with any part of the above. End-user data
is precious no matter the volume, and we keep notes by making them
reachable from refs in the refs/notes/ hierarchy.
I am not sure what qualifies, in your eyes, "good" way, but "git
notes prune" is a good way to remove notes that are attached to
objects that have already been pruned away.
^ permalink raw reply [relevance 4%]
* Re: [PATCH 5/8] rebase: preserve interactive todo file on checkout failure
@ 2023-03-23 23:23 4% ` Oswald Buddenhagen
0 siblings, 0 replies; 200+ results
From: Oswald Buddenhagen @ 2023-03-23 23:23 UTC (permalink / raw)
To: git
On Thu, Mar 23, 2023 at 01:16:47PM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>
>> Creating a suitable todo file is a potentially labor-intensive process,
>> so be less cavalier about discarding it when something goes wrong (e.g.,
>> the user messed with the repo while editing the todo).
>
>Is there a reason why we do not always keep it? Why is the file
>sometimes precious but not precious at all in other times?
>
the unedited initial todo just isn't precious. that implies that in a
non-interactive rebase, it is always worthless at the time of the
initial reset.
>Tying the previous bit to "-i was explicitly given" feels a bit
>unintuitive---when the sequencer machinery was implicitly chosen,
>and gives the control back to the user, should a user be forbidden
>to muck with the todo list?
>
that would be an --edit-todo and --continue during a mid-rebase stop.
rather different case.
>No // comments, please.
>
(apparently with a special exception for examples in the apidocs,
presumably because escaping nested comments would be just too ugly.)
>> - test_path_is_missing .git/rebase-merge &&
>> + test_path_is_dir .git/rebase-merge &&
>
>Are we happy to just see that the directory still exists? I thought
>the original motivation explained in the proposed log message was to
>keep the todo list file, so shouldn't you be checking if the file is
>there
>
fair point.
>(and if you can reliably ensure that the file has contents
>that are expected, that would be even better)?
>
i could grep for a shortened sha1 i would obtain from the branch. but
given that the error scenario of a present but somehow corrupted todo
seems implausible given the circumstances, that seems like overkill.
>Also, as the keeping of the todo list is now conditional, we should
>have another test that checks that the file is gone when that
>condition ("INTERACTIVE_EXPLICIT"?) does not trigger, I think.
>
that would be for t3400-rebase.sh.
i suppose we could extend 'Show verbose error when HEAD could not be
detached'.
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
@ 2012-07-09 19:38 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2012-07-09 19:38 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, Michał Górny, Phil Hord, Heiko Voigt
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Cool, so let's drop this patch and I'll teach "rm" to handle
> populated submodules according to what we do for regular files:
> Make sure there are no modifications which could get lost (unless
> "-f") and remove all tracked files and the gitfile from the work
> tree (unless "--cached") before removing the submodule from the
> index. If the submodule uses the old layout with the .git
> directory instead of a gitfile we error out just like we do today.
Alternatively we could "mv" .git directory out of the way and the
next "git checkout" of a branch that still has the submodule can
make a gitfile to point there, no?
Or we can just error out and tell the user to do so herself.
> And we didn't talk about untracked or ignored files which may live
> inside the submodules work tree so far, but according to what a
> "rm -r" does in the superproject they should still be around after
> using "rm" on a populated submodule, right?
Until we add the "precious" class, untracked and ignored files are
expendable, so if a submodule working tree has no modification and
only has leftover *.o files, they can be nuked as part of submodule
removal, but if it has an untracked and unignored *.c file for
example, the "rm" operation without "-f" should be stopped, no?
^ permalink raw reply [relevance 4%]
* Re: Bug report - local (and git ignored) file silently removed after checkout
@ 2011-11-20 21:16 4% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2011-11-20 21:16 UTC (permalink / raw)
To: Bertrand BENOIT; +Cc: git
Bertrand BENOIT <projettwk@users.sourceforge.net> writes:
> Context:
> - in previous version of my project, the TODO file was versioned
> - in current development version, this file is NO more versioned AND
> it is ignored by a gitignore rule,...
What you observed is expected with all the versions of Git since the
gitignore mechanism was introduced. The ignored files are "not tracked,
are cruft that can be removed to make room if it is necessary for checking
out a tracked version, and would not want to track (e.g. build artifacts
like '*.o')" (I am not saying that it is the most sane semantics, I am
just stating the fact).
We do not have "not tracked, but precious (e.g. your TODO)" category; from
time to time we have discussed possibilities of adding such to enrich the
categorization, but nobody stepped up to actually do the work of designing
let alone coding such a beast.
^ permalink raw reply [relevance 4%]
* Re: What's cooking in git.git (Oct 2023, #01; Mon, 2)
@ 2023-10-05 20:59 4% ` Sergey Organov
0 siblings, 0 replies; 200+ results
From: Sergey Organov @ 2023-10-05 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> Sergey Organov <sorganov@gmail.com> writes:
[...]
>>> If I have to pick a candidate for "get me diff" that is the most
>>> useful among those currently are available, it is "give patches to
>>> all single-parent commit, and show tricky conflict resolution part
>>> only for merge commits".
>>
>> I'm afraid you need to pick a candidate that will be natural for '-d',
>> not just most useful output for your workflows, whatever it happens to
>> be.
>
> Literal match to word "diff" does not necessarily mean it is useful,
Sure, who argues? I don't.
> and short-and-sweet single-letter option name is primarily about
> letting users reach useful features with minimum typing [*1*], so you
> cannot avoid "most useful" being a large part of the equation.
I don't try to avoid "most useful" either, quite opposite. With whom do
you argue?
I just pointed that a short-cut would better be natural (or mnemonic)
/as well/, so you probably don't actually want:
-d:
give patches to all single-parent commits, and show tricky conflict
resolution part only for merge commits.
, or do you?
Overall, as an example, I'd understand if you had deflected the patch
with "let's rather use -d for '--decorate=short', or '--date=relative'",
or something like that, but you don't, leaving me uncertain about your
actual worries and intentions.
Anyway, I re-submitted the patches avoiding precious, too hard to
deserve single-letter option.
Thanks,
-- Sergey Organov
^ permalink raw reply [relevance 4%]
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
@ 2005-12-01 8:08 4% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2005-12-01 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Timo Hirvonen, git
Hi,
On Wed, 30 Nov 2005, Junio C Hamano wrote:
> Honestly speaking, I'd personally prefer to just get rid of "-include
> config.mak" from Makefile.
But it is only one line, heck only 20 bytes!
And you can still use your "./Make" method, and it is not widely
advertised, and you can override settings from the platform-dependent
code, and I feel much better at having my littly config.mak, my precious!
Ciao,
Dscho
^ permalink raw reply [relevance 4%]
* Re: How to resolve git-am conflict (possible bug)
@ 2006-08-12 9:10 4% ` Jakub Narebski
0 siblings, 0 replies; 200+ results
From: Jakub Narebski @ 2006-08-12 9:10 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Third, I wonder why it printed the same error message _twice_.
>
> Do you have blob 7ea52b1? Otherwise you would not see two "does
> not apply" messages, so I suspect you do. Does the patch
> cleanly apply to that blob?
>
> More likely explanation is that you edited the patch by hand for
> some reason, and made it inapplicable to the base blob the
> "index" line records.
Yes, I have edited "post-sub-rename" patch by hand (by script) in attempt
for it to apply cleanly to the top of "pre-sub-rename" development branch.
BTW patch applies cleanly to merge-base of the branch the patch is from and
the branch it is applied to.
Why do we not record commit id in patch? And how git-rebase deals with this?
> The first "patch does not apply" comes from ll. 363 of git-am.
> After it fails because the patch does not apply to the version
> of gitweb.perl in your index, since you told it to fall back to
> three-way merge, l. 391 calls fall_back_3way, which inspects the
> patch, finds the "index" line and notices that the patch claims
> to apply to blob 7ea52b1, finds the blob in your repository, and
> prepares a temporary index with "update-index -z --index-info"
> on l. 58 successfully, tries to apply the patch again on l. 63.
>
> However, the patch contents and the blob object name recorded on
> the index line are not necessarily consistent if you hand edited
> the patch (IOW, the context lines in the patch contents may not
> match blob 7ea52b1).
It would be nice then if git-am was more verbose, for example
"Applying patch to blob 7ea52b1... gitweb/gitweb.perl" or something
like that.
And first complaint still apply: in git-am(1) there is precious few
documentation (or at least references) about _how_ to resolve merge
conflict or failed patch (does git-apply creates *.orig and *.rej
files?)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 4%]
* Re: Marking abandoned branches
@ 2006-09-13 15:24 4% ` Petr Baudis
0 siblings, 0 replies; 200+ results
From: Petr Baudis @ 2006-09-13 15:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> Abandoned branches are common in CVS since it is not distributed.
> People start working on something in the main repo and then decide it
> was a bad idea. In the git world these branches usually don't end up
> in the main repo.
Can't you just toss the branch away in that case? :-)
You could also stash the ref to refs/heads-abandoned/ instead of
refs/heads/ if you want to keep the junk around for some reason. Of
course you don't get the nice marker with explanation of why is this
abandoned and who decided that, but you can just use an empty commit for
the same purpose.
Object classes are precious things and we shouldn't get carried away.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply [relevance 4%]
* Re: [PATCH] git-reset --hard: use quotes when we tell the user what HEAD was reset to
@ 2007-01-06 19:26 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2007-01-06 19:26 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
Fredrik Kuivinen <freku045@student.liu.se> writes:
> Idea and motivating example from Andy Whitcroft:
>
> apw@pinky$ git checkout -b bar master
> apw@pinky$ git reset --hard ac9c1108d8915f0937795e354ad72c4ae6890a3f
> HEAD is now at ac9c110... git-fetch: remove .keep file at the end.
>
> Huh, fetch? Remove what .keep file? Did I do a fetch? What?
>
> I think we need to delimit the name better, probabally we need to quote
> it. Perhaps something like:
>
> HEAD is now at ac9c110: "git-fetch: remove .keep file at the end".
I've also considered something along that line, but:
(1) I think this 'confusion' is only because you are futzing
with a project that deals with git-fetch and friends and
not a general problem.
(2) With "HEAD is now at xxxxx..." prefix, even two characters
are precious to fit the title of the commit on a single
line.
With these in mind, do you still want to do this?
^ permalink raw reply [relevance 4%]
* Re: [PATCH] detached HEAD -- finishing touches
@ 2007-02-02 1:11 4% ` Junio C Hamano
2007-02-02 1:16 4% ` Theodore Tso
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2007-02-02 1:11 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jeff King, Nicolas Pitre, cworth, git
Theodore Tso <tytso@mit.edu> writes:
> On Thu, Feb 01, 2007 at 01:08:41AM -0800, Junio C Hamano wrote:
>> [git.git]$ git checkout master
>> You are not on any branch and switching to branch 'master'
>> may lose your changes. At this point, you can do one of two things:
>> (1) Decide it is Ok and say 'git checkout -f master';
>> (2) Start a new branch from the current commit, by saying
>> 'git checkout -b <branch-name>'.
>> Leaving your HEAD detached; not switching to branch 'master'.
>
> How hard would it be to simply simply set a flag once git has entered
> a detached HEAD state, and clear the flag if any git operation has
> modified the repository at all. If the flag is still set, then
> obviously the repository hasn't changed and so there are no changes
> that could be lost.
Didn't I already point out that you can have a precious
information while on the detached HEAD without making any
commit, and that is the reason why we do not use the
reachability crud from refs when deciding to issue the message?
^ permalink raw reply [relevance 4%]
* Re: [PATCH] detached HEAD -- finishing touches
2007-02-02 1:11 4% ` Junio C Hamano
@ 2007-02-02 1:16 4% ` Theodore Tso
0 siblings, 0 replies; 200+ results
From: Theodore Tso @ 2007-02-02 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Nicolas Pitre, cworth, git
On Thu, Feb 01, 2007 at 05:11:09PM -0800, Junio C Hamano wrote:
> Didn't I already point out that you can have a precious
> information while on the detached HEAD without making any
> commit, and that is the reason why we do not use the
> reachability crud from refs when deciding to issue the message?
Sorry, I must be dense. Exactly what precious information can be ever
be lost in the following sequence:
git checkout HEAD~1
git checkout master
such that it want to train users to be typing
git checkout -f master
instead?
- Ted
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
@ 2007-07-06 3:18 4% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2007-07-06 3:18 UTC (permalink / raw)
To: Josh Triplett; +Cc: Jeff King, git
Hi,
On Thu, 5 Jul 2007, Josh Triplett wrote:
> bash has "set -o pipefail", but that would require bash. However, you
> could try setting pipefail, and ignoring any failure to set it; that
> would give the more friendly behavior with bash, while still allowing
> any /bin/sh in general.
I was aware of pipefail when I wrote that patch. However, I have zero
interest in a "solution" which works on bash, but fails on other shells.
That is like allowing a precious few to overstep some serious line (and
commuting them), but severely punish all others. And that's wrong. And
to allow it to happen is wrong, too.
Ciao,
Dscho
^ permalink raw reply [relevance 4%]
* [PATCH 0/4] Add git-rewrite-commits
@ 2007-07-08 16:23 4% skimo
0 siblings, 0 replies; 200+ results
From: skimo @ 2007-07-08 16:23 UTC (permalink / raw)
To: git, Junio C Hamano
From: Sven Verdoolaege <skimo@kotnet.org>
This patch series adds git-rewrite-commits
and depends (for the tests in the fourth part)
on my earlier patch to allow negative matches
(or an extended patch by Johannes).
[PATCH 1/4] export get_short_sha1
[PATCH 2/4] export add_ref_decoration
[PATCH 3/4] revision: mark commits that didn't match a pattern for later use
[PATCH 4/4] Add git-rewrite-commits
The first two should be fairly uncontroversial.
The third may be considered a waste of a precious bit.
If so, any suggestions for other ways of passing on this information
are welcomed.
The fourth contains the actual git-rewrite-commits builtin.
My main motivation was that cg-admin-rewritehist doesn't
change the SHA1's in commit message and I don't like shell
programming.
skimo
^ permalink raw reply [relevance 4%]
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
@ 2007-08-07 8:51 4% ` Sven Verdoolaege
0 siblings, 0 replies; 200+ results
From: Sven Verdoolaege @ 2007-08-07 8:51 UTC (permalink / raw)
To: Eran Tromer; +Cc: Junio C Hamano, git
On Mon, Aug 06, 2007 at 11:24:46PM -0400, Eran Tromer wrote:
> On 2007-08-06 15:03, Sven Verdoolaege wrote:
> >>>> Another approach is for pull, checkout etc. to automatically update the
> >>>> submodule' head ref, but no more.
> >>> Then everything, including "git submodule update", would assume
> >>> that the submodule is up-to-date.
> >> With that approach, "git submodule update" would fetch the submodule's
> >> head commit (which could be missing), and then check it against the
> >> submodule's index (and maybe its work tree).
> > And how is anyone supposed to figure out what HEAD the submodule's
> > index and working tree correspond to?
>
> What HEAD corresponds to any other dirty index or dirty working tree?
> It's irrelevant and may not exist. You just have some random dirty state.
The only way to know that it's dirty is if you know the HEAD.
How can that not be relevant.
> > I can only hope that "git submodule update" would never blindly assume
> > that the submodule is clean and so the user would have to manually
> > sync the HEAD and the working tree.
>
> Why would it assume that? In this approach, and ignoring submodule
> merging for now, "git submodule update" should mean roughly "cd
> submodule && git fetch HEAD && git reset --hard HEAD".
If you're doing that, then that is exactly what you are assuming.
> After all, this
> is really the only way to end up with the prescribed commit sha1.
That's the best way of losing all you precious changes in the submodule.
And there is no way to get them back!
Surely this is a lot worse than occasionally committing something you
didn't plan to commit, and only if you are performing a known "dangerous"
operation.
> I agree that for safety it makes sense to warn or abort if the index
> doesn't match ORIG_HEAD (saved by the supermodule checkout) or if the
> index doesn't match the work tree.
You may have done several supermodule checkouts since you last changed
the submodule.
skimo
^ permalink raw reply [relevance 4%]
* Re: Extending .gitignore
@ 2007-08-18 10:00 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2007-08-18 10:00 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:
> So I want to be able to say to git: don't track this file, but don't delete it either (even with clean -x).
> What do you think? Does it make sense? Can it be done right now?
I've said that we would need .precious in addition to .ignore;
no objection at all, except "even with clean -x" part which may
be a controversial detail.
Can it be done right now? Of course not. That is definitely a
post 1.5.3 item.
But the beauty of the distributednes of git is that _you_ can
start working on it without disturbing anybody else nor worrying
about the stabilization freeze period.
Me, personally I would prefer to see people spending their time
to find regressions in -rc and fixing them before the release,
though...
^ permalink raw reply [relevance 4%]
* Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.
@ 2007-08-26 7:28 4% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2007-08-26 7:28 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:
> I thought I did: I've observed that these problem are caused by
> storing metadata in regular files (that exist both in repo/index and
> in workplace).
And that observation solves the initial checkout issue how?
> My knowledge of Git internals is quite limited, but if *I* were to do
> it right now, I'd introduce a META entry in every TREE object that
> would point to a BLOB that contains combined content of
> .gitattributes, .gitignore etc.
A tree that has .gitattributes (and I am assuming in the longer
term you can use "ignore" and "precious" in .gitattributes
instead of using .gitignore) POINTS TO A BLOB already, so what
you are saying does not add anything to what we already have,
other than that you are renaming .gitattributes to "META ENTRY".
When you do "git checkout -- this-path", you are checking things
out from the index and at that point you may not have _any_ tree
yet (think "before initial commit"). A "META ENTRY" that exists
only in a tree does not work -- it has to come to index somehow
for it to work with how git works.
^ permalink raw reply [relevance 4%]
* Re: [PATCH] git-merge: add option --no-ff
@ 2007-09-18 12:38 4% ` Lars Hjemli
0 siblings, 0 replies; 200+ results
From: Lars Hjemli @ 2007-09-18 12:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
[...stripped the Cc, as we're slightly changing topic...]
On 9/18/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 18 Sep 2007, Lars Hjemli wrote:
> > Sidenote: this might be slightly controversial, but I've sometimes
> > missed a --no-ff option to 'git merge' when working on plain git
> > repositories; IMHO preserving the 'logical' merge history when the merge
> > of a topic branch results in a fast-forward can be interesting.
>
> Linus explained a lot of times why this is wrong. It encourages
> upstream-downstream thinking. We should really turn this into a FAQ.
Well, the cases where I've wanted to do this is when I've developed
some new feature in cgit as a topic branch. I've then merged the topic
branch into my master branch which had been idle since the creation of
the topic branch (cgit doesn't get as many patches as git...). So I
get a fast-forward and my precious topic-branch is no longer visible
(at least for anyone cloning my repo). Not very important, but I'd
like to preserve the fact that this was a topic branch. How would this
encourage 'upstream-downstream thinking'?
--
larsh
^ permalink raw reply [relevance 4%]
* Re: making "git stash" safer to use
@ 2007-10-03 21:36 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2007-10-03 21:36 UTC (permalink / raw)
To: Bruno Haible; +Cc: git, Benoit SIGOURE, Eric Blake
Bruno Haible <bruno@clisp.org> writes:
>> While we're at it, I wish 'git stash clear' would take an optional
>> argument that says which stash(es) to clear, rather than blindly clearing
>> the entire stash.
>
> It would help if git would store which of the stashes were applied since
> they were created and which were not. A stash that was not yet applied must
> be considered "precious", whereas a stash that was applied is redundant,
> right?
Wrong. I would say all stash entries are precious unless you
explicitly say "I'm done with it". The problem is that we do
not have a way to say it explicitly.
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
@ 2007-10-05 8:21 4% ` Peter Baumann
0 siblings, 0 replies; 200+ results
From: Peter Baumann @ 2007-10-05 8:21 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
On Thu, Oct 04, 2007 at 05:15:28PM -0700, Steven Grimm wrote:
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling. Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.
>
I don't like the automatic prune. What if someone has other objects in
there which shouldn't be pruned? Making git svn dcommit doing the prune
would be at least suprising, because how is one supposed to know that
doing a commit into svn will prune all your precious objects?
Sure, I can unterstand from where you are coming from, but I'd prefere
if this could be specified on a case by case basis, e.g. from the
cmdline or as a config option.
-Peter
> git-svn.perl | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
> }
> command_noisy(@finish, $gs->refname);
> $last_rev = $cmt_rev;
> +
> + # rebase will have made the just-committed revisions
> + # unreachable; over time that can build up lots of
> + # loose objects in the repo. prune is unsafe to run
> + # concurrently but so is dcommit.
> + command_noisy(qw/gc --auto --prune/);
> }
> }
> }
> --
> 1.5.3.4.203.gcc61a
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [relevance 4%]
* Re: git-svnimport
@ 2007-10-25 22:20 4% ` Steven Walter
0 siblings, 0 replies; 200+ results
From: Steven Walter @ 2007-10-25 22:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Felipe Balbi, git
On Thu, Oct 25, 2007 at 02:04:29PM +0100, Johannes Schindelin wrote:
> FYI you'll have to do something like this:
>
> git svn init svn://busybox.net/trunk/busybox
> git svn fetch
>
> to merge with current busybox (although I updated before I pushed).
More than that, you'll want to:
git svn init <foo>
cp .git/refs/remotes/origin/master .git/refs/remotes/git-svn
git svn fetch
If git-svn doesn't find a remote named "git-svn" it will assume that it
has no information about the repository and starting doing a full
checkout. By copying the ref, git-svn will see that there are already
commits with git-svn-id lines and rebuild its "rev-db". After that, it
will incrementally update for newer revisions.
That ought to save you a few precious minutes :)
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
^ permalink raw reply [relevance 4%]
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
@ 2007-11-13 23:56 4% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2007-11-13 23:56 UTC (permalink / raw)
To: Matthieu Moy
Cc: Brian Gernhardt, Shawn O. Pearce, Junio C Hamano, Bill Lear,
Jan Wielemaker, git
Hi,
On Tue, 13 Nov 2007, Matthieu Moy wrote:
> I would just appreciate if people stopped calling me (and other users
> interested in a sane empty clone behavior) idiot because I think it
> would make sense to do it.
Oh, come on. Nobody called _you_ idiot.
But I illustrated that cloning from an empty repository makes no sense.
There is a huge difference between calling somebody an idiot on the one
side, and investing some time to help somebody who has a suboptimal
workflow on the other one.
But I fear that you took my help as a personal attack, and as a
consequence you feel insulted, and I wasted my precious time.
Ciao,
Dscho
^ permalink raw reply [relevance 4%]
* Re: Something is broken in repack
@ 2007-12-13 16:39 4% ` Johannes Sixt
0 siblings, 1 reply; 200+ results
From: Johannes Sixt @ 2007-12-13 16:39 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, gcc
Paolo Bonzini schrieb:
> Nguyen Thai Ngoc Duy wrote:
>> On Dec 12, 2007 10:48 PM, Nicolas Pitre <nico@cam.org> wrote:
>>> In the mean time you might have to use only one thread and lots of
>>> memory to repack the gcc repo, or find the perfect memory allocator to
>>> be used with Git. After all, packing the whole gcc history to around
>>> 230MB is quite a stunt but it requires sufficient resources to
>>> achieve it. Fortunately, like Linus said, such a wholesale repack is not
>>> something that most users have to do anyway.
>>
>> Is there an alternative to "git repack -a -d" that repacks everything
>> but the first pack?
>
> That would be a pretty good idea for big repositories. If I were to
> implement it, I would actually add a .git/config option like
> pack.permanent so that more than one pack could be made permanent; then
> to repack really really everything you'd need "git repack -a -a -d".
It's already there: If you have a pack .git/objects/pack/pack-foo.pack, then
"touch .git/objects/pack/pack-foo.keep" marks the pack as precious.
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: Something is broken in repack
@ 2007-12-14 6:24 4% ` Nguyen Thai Ngoc Duy
0 siblings, 0 replies; 200+ results
From: Nguyen Thai Ngoc Duy @ 2007-12-14 6:24 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, gcc
On Dec 14, 2007 1:14 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> > Hmmm... it is even documented in git-gc(1)... and git-index-pack(1) of
> > all things.
>
> I found that the .keep file is not transmitted over the network (at
> least I tried with git+ssh:// and http:// protocols), however.
I'm thinking about "git clone --keep" to mark initial packs precious.
But 'git clone' is under rewrite to C. Let's wait until C rewrite is
done.
--
Duy
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/4] help: make 'git-help--browse' usable outside 'git-help'.
@ 2008-02-03 5:00 4% ` Christian Couder
0 siblings, 0 replies; 200+ results
From: Christian Couder @ 2008-02-03 5:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
Le samedi 2 février 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > + struct strbuf page_path; /* it leaks but we exec bellow */
> > +
> > + get_html_page_path(&page_path, page);
> > +
> > + execl_git_cmd("help--browse", page_path.buf, NULL);
> > }
>
> And this part makes the reviewer even more worried. If page
> could be NULL, then get_html_page_path() would be fed a NULL
> pointer, which is given to strbuf_addf()! Ugh.
>
> Then the reviewer would find out that cmd_to_page() would never
> return NULL, as it has its own NULL-to-"git" fallback logic.
>
> I think the code is good, but the proposed commit log message
> has some room for improvements.
Yeah, I could have explained some parts of the patch more.
I will try to do better.
> Something like...
>
> [PATCH 1/4] help: make 'git-help--browse' usable outside 'git-help'
>
> "git-help--browse" helper is to launch a browser of the
> user's choice to view the HTML version of git documentation
> for a given command. It used to take the name of a command,
> convert it to the path of the documentation by prefixing the
> directory name and appending the ".html" suffix, and start
> the browser on the path.
>
> This updates the division of labor between the caller in
> help.c and git-help--browser helper. The helper is now
> responsible for launching a browser of the user's choice
> on given URLs, and it is the caller's responsibility to
> tell it the paths to documentation files.
>
> This is in preparation to reuse the logic to choose
> user's preferred browser in instaweb.
>
> The helper had a provision for running it without any
> command name, in which case it showed the toplevel "git(7)"
> documentation, but the caller in help.c never makes such a
> call. The helper now exits with a usage message when no
> path is given.
Great commit message indeed! Though I fear that such long messages (for a
not very long patch) could take precious screen real estate when using "git
log" or otherwise bother some other readers.
Anyway do you want me to resend the patch or the series with improved commit
messages ?
> Signed-off-by: ...
> ---
>
> * Eric is CC'ed because the ultimate goal of this
> series is to get rid of the duplicated logic between
> help--browse and instaweb.
>
> Makefile | 2 +-
> git-help--browse.sh | 24 +++++++++---------------
> ...
>
> I have given only a cursory look at the remainder of the series
> (I'll hopefully be in a mini vacation mode after the release),
You definitely deserve it. Thanks for your great release and maintainer
work.
> but I think overall the series makes sense.
Thanks,
Christian.
^ permalink raw reply [relevance 4%]
* Re: [PATCH,RFC] Implement 'git rm --if-missing'
@ 2008-07-16 18:06 4% ` Petr Baudis
0 siblings, 0 replies; 200+ results
From: Petr Baudis @ 2008-07-16 18:06 UTC (permalink / raw)
To: Ciaran McCreesh; +Cc: git
Hi,
On Wed, Jul 16, 2008 at 07:00:50PM +0100, Ciaran McCreesh wrote:
> git rm --if-missing will only remove files if they've already been removed from
> disk.
>
> Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
what is the usage scenario? The porcelain options space is a precious
resource, so please explain why do you need this and who is going to use
it (especially with such a long name).
Petr "Pasky" Baudis
^ permalink raw reply [relevance 4%]
* Re: [FYI PATCH] git wrapper: DWIM mistyped commands
@ 2008-07-22 20:37 4% ` Alex Riesen
0 siblings, 0 replies; 200+ results
From: Alex Riesen @ 2008-07-22 20:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin, Tue, Jul 22, 2008 22:01:29 +0200:
> As a convenience, if there is only one candidate, Git continues under
> the assumption that the user mistyped it. Example:
>
> $ git reabse
> WARNING: You called a Git program named 'reabse', which does
> not exist.
> Continuing under the assumption that you meant 'rebase'
> [...]
Oh, that would make me suspicios (and I hit Ctrl-C fast when I get
suspicios about what happens to my precious data). Could it be
configurable? For example, BASH's cdspell is configurable and even off
by default.
P.S. I'm still using your first patch and am forced to like it every day :)
^ permalink raw reply [relevance 4%]
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
@ 2008-10-06 20:11 4% ` Heikki Orsila
0 siblings, 0 replies; 200+ results
From: Heikki Orsila @ 2008-10-06 20:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Jakub Narebski, Petr Baudis, msysgit, git
On Mon, Oct 06, 2008 at 08:01:38PM +0200, Johannes Schindelin wrote:
> It is not a bug. It is a message that tells the Windows user that this is
> GPLed software, and that they are free to copy it. Windows users (and
> developers on Windows are more of users than developers) are often not
> aware of that fact.
>
> That is the reason why many Open Source projects do not bother on Linux,
> but do bother on Windows.
It's pointless and harmful to present any non-relevant information for
users. I simply hate programs that waste my precious seconds. I want it
NOW, not soon. Developers can tell the license if they want to
distribute it, but users do not need it at all.
> So I guess we simply disagree here.
I disagree VIOLENTLY with you. I've been utterly struck with this
Windows crap here.. I spent a day installing stupid trivial software
and answering pointless EULAs. I REALLY REALLY hate extra questions..
This is my 20th reboot..
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply [relevance 4%]
* Re: Usability of git stash
@ 2008-10-20 5:23 4% ` Miles Bader
0 siblings, 0 replies; 200+ results
From: Miles Bader @ 2008-10-20 5:23 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Brandon Casey, David Kastrup, git
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> I wonder whether experienced users even use stash a lot. Personally,
> after getting my head around the DAG, and thus getting more
> comfortable with git reset, I tend to make "WIP" commits instead.
I certainly do, and my impression is that some of the biggest boosters
of stash have always been the git heavy hitters (it's certainly not one
of these "implemented due to nagging by newbies" features)...
-Miles
--
Liberty, n. One of imagination's most precious possessions.
^ permalink raw reply [relevance 4%]
* Re: [PATCH/RFC] Documentation/git-mailsplit.txt: Emphasize -o more
@ 2009-01-12 22:55 4% ` jidanni
0 siblings, 0 replies; 200+ results
From: jidanni @ 2009-01-12 22:55 UTC (permalink / raw)
To: gitster; +Cc: git
All I know is the user had better not forget -o<directory> or else his
precious mailbox will be interpreted as something else... Actually the
problem is with builtin-mailsplit.c,
$ git mailsplit -o
fatal: unknown option: -o
One big tangle. So I would just say
+ certain backward compatibility mode (that we won't detail here).
^ permalink raw reply [relevance 4%]
* Re: "mailinfo: Remove only one set of square brackets" considered harmful
@ 2009-07-15 22:09 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2009-07-15 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Git Mailing List
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So I see why Andreas did it, and I don't disagree violently, BUT...
>
> The fact is, we have mailing lists etc that add their own headers to the
> subject, and they know they can add things in brackets. The most obvious
> example is the Linux kernel security list, which adds a prefix of
>
> "[Security] "
>
> to the subject line in order to stand out (I'm on other lists that do
> this too, but those generally don'thave patches).
>>
> So I have emails witgh subjects like
>
> Subject: [Security] [patch] random: make get_random_int() more random
>
> but I also have people who do the same thing themselves, eg:
>
> Subject: [PATCH -rc] [BUGFIX] x86: fix kernel_trap_sp()
> Subject: [BUGFIX][PATCH] fix bad page removal from LRU (Was Re: [RFC][PATCH] ..
>
> so people did kind of depend on the "remove square brackets" behavior.
Thanks. The reason why I have merged some questionable stuff (including
this one) early in this cycle was exactly because we would want to catch
real world breakages caused by such changes.
Even though it is silly not to rely on already well established
conventions such as X-Mailing-List and List-ID but instead to waste
precious real estate at the initial part of the Subject in this century
merely for list identification purposes, this change regresses the end
result.
^ permalink raw reply [relevance 4%]
* Re: .gitignore vs untracked working file
@ 2009-08-10 11:41 4% ` Johannes Sixt
0 siblings, 0 replies; 200+ results
From: Johannes Sixt @ 2009-08-10 11:41 UTC (permalink / raw)
To: Rostislav Svoboda; +Cc: git, Uwe Kleine-König
Rostislav Svoboda schrieb:
> 2009/8/10 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> Hello,
>>
>>> $ git checkout master
>>> error: Untracked working tree file 'Project/bin/path/file.jjt' would
>>> be overwritten by merge.
>> What is the output of
>>
>> $ git ls-files master bin/
>
> Nothing:
It should have been
$ git ls-tree master bin
> BTW the rule to ignore bin/ is exclusively in the .gitignore on the
> branch mybranch not in the master branch. Might this be the problem?
It might be, depending on how precious Project/bin/path/file.jjt is for
you. Try this:
$ git checkout -f master
This will overwrite the existing file with the version from master. If you
later
$ git checkout mybranch
then the file will be *removed*.
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: Question regarding git fetch
@ 2009-08-27 21:50 4% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2009-08-27 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Björn Steinbrink, Tom Lambda, git
On Thu, Aug 27, 2009 at 02:44:54PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > # we usually fetch the remote's master straight into our production
> > # branch for deployment
> > $ git config remote.origin.fetch refs/heads/master:refs/heads/production
> >
> > # but today let's demo it first
> > $ git fetch origin master:demo
>
> I think this is a good example that any change results from this
> discussion should apply _only_ to cases where command line refspecs lack
> colon (i.e. used to mean "do not store this anywhere but in FETCH_HEAD").
I don't think the colon is the issue. Consider the same situation, but I
say:
# but today let's demo it first
$ git fetch origin master
$ git checkout -b demo FETCH_HEAD
I'm still screwed. The issue is that you consider your configured
refspec destinations to be precious, and not merely a cache for what's
happening on the remote side.
-Peff
^ permalink raw reply [relevance 4%]
* Re: Commit to wrong branch. How to fix?
@ 2009-09-04 18:01 4% ` Howard Miller
0 siblings, 0 replies; 200+ results
From: Howard Miller @ 2009-09-04 18:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git@vger.kernel.org
Hi Michael,
Thanks for your help.
I had modified a few files and then done a 'git commit -a'. It was
only after this that I did a status and realised that I had switched
to a different branch (and forgotten). Unfortunately the branch I
switched to tracks a remote that is my stable release so I'm a bit
precious about it. If I forget again and push it, I'm in trouble :-)
Yes, I have done that before!!
Howard
2009/9/4 Michael J Gruber <git@drmicha.warpmail.net>:
> Howard Miller venit, vidit, dixit 04.09.2009 17:54:
>> I commited to the wrong branch and I can't figure out what to do. To
>> make matters worse I then did 'git reset HEAD^' which has made things
>> much worse. It didn't remove the commit and now I can't change
>> branches. I'm utterly confused. Any help much appreciated!
>>
>> Moral - use git status liberally and read it carefully before doing
>> anything. A 'git undo" command would be great is someone is feeling
>> generous :-)
>
> Whatever happens, don't panic ;)
>
> Let's say "geesh" is the branch on which you committed by mistake, and
> which you have reset.
>
> git reflog geesh
>
> which show you what has happened to that branch lately. In particular,
> it will list the "lost" commit. (Most probably it is the same as geesh@{1}.)
>
> git tag sigh sha1ofthatcommit
>
> will assign the tag "sigh", so that it won't get lost by doing "git gc"
> or such. Now you can lean back!
>
> Next step is committing "sigh" to the right branch. Depends on how you
> arrived at that commit. Did you commit the complete tree you wanted, or
> did you apply a change to geesh which you rather had wanted applied to
> some other branch?
>
> Michael
>
^ permalink raw reply [relevance 4%]
* Re: obnoxious CLI complaints
@ 2009-09-10 18:52 4% ` Sverre Rabbelier
0 siblings, 0 replies; 200+ results
From: Sverre Rabbelier @ 2009-09-10 18:52 UTC (permalink / raw)
To: Eric Schaefer; +Cc: git
Heya,
On Thu, Sep 10, 2009 at 20:18, Eric Schaefer
<eric.schaefer@ericschaefer.org> wrote:
> "Unimportant bug reports"? Interesting concept... ;-)
Sure, if there's a bug in feature foo, but it only happens when
invoking it with some rarely used argument, and only on Solaris
platforms, it is probably not worth spending time on it if the
original reporter does not even have the time to stick around and aid
in resolving the issue. It's probably better to spend that precious
time on other bug fixes, or features instead.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 4%]
* Re: git-svn problem with v1.6.5
@ 2009-11-12 8:11 4% ` Pascal Obry
0 siblings, 0 replies; 200+ results
From: Pascal Obry @ 2009-11-12 8:11 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, adambrewster, git list
Eric,
> Oh... Any chance that lost commit you couldn't find was clobbered
> by filter-branch? That would explain a lot...
I still have the AWS repo as it was from initial import. And I can see
the commit
on this one:
$ git log --all --parents | grep d2cf08bb67e4b7da33a250127aab784f1f2f58d3
commit bd95b2b254286e6f04015b7f58266d66abc134a7
d2cf08bb67e4b7da33a250127aab784f1f2f58d3
commit d2cf08bb67e4b7da33a250127aab784f1f2f58d3
406eaf7e51229f60048ea80cdb6904e33ef59a81
So that's definitely a problem with the filter-branch. Thanks a lot
for your precious help!
Will review the procedure for filtering branches :(
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply [relevance 4%]
* Re: GSoC draft proposal: Line-level history browser
@ 2010-03-21 6:16 4% ` Bo Yang
0 siblings, 1 reply; 200+ results
From: Bo Yang @ 2010-03-21 6:16 UTC (permalink / raw)
To: gitzilla; +Cc: Alex Riesen, git
On Sun, Mar 21, 2010 at 5:58 AM, A Large Angry SCM <gitzilla@gmail.com> wrote:
> Alex Riesen wrote:
>>
>> On Sat, Mar 20, 2010 at 10:18, Bo Yang <struggleyb.nku@gmail.com> wrote:
>>>
>>> <line range>
>>> Its format should be <start pos>..<end pos> or just a <line number>.
>>
>> You might want to reconsider the line range syntax. Exactly the same
>> syntax
>> is already used to specify a commit range, so reusing it may lead to
>> confusion.
>
> I, actually, think the proposed line range syntax works because it uses the
> same _range_ notation. The issue is how to differentiate the _line_ range(s)
> from the _commit_ range(s); and, yes, I would like multiple ranges of each
> type as well as multiple files.
As what I said in previous post, I think we should adopt 'git blame'
way. Use a '-L <start pos>,<end pos>' to specify the line range. It
support both line number and posix regex.
For multiple ranges stuff, I don't think it is very useful to support
it for a history browser. Anyway, our users can only focus on one line
of thread history. I am very willing to listen what is your use case
for a multiple ranges?
Thanks for your precious advice!
Regards!
Bo
^ permalink raw reply [relevance 4%]
* Re: GSoC draft proposal: Line-level history browser
@ 2010-03-24 2:30 4% ` Bo Yang
0 siblings, 0 replies; 200+ results
From: Bo Yang @ 2010-03-24 2:30 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jakub Narebski, Junio C Hamano, gitzilla, Alex Riesen, git
Hi,
On Wed, Mar 24, 2010 at 3:57 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Bo Yang wrote:
>
>> It traces the preimage of the minimum related diff hunk carefully, if
>> there is any case that there are more than one commit intersect with
>> the preimage, we will stop and ask the users to select which way to go
>> on tracing.
>
> That might be necessary, but I will admit that I suspect it to be
> harder to make useful. One of the very nice things about ‘git log’ is
> that it is easy to browse through history in a nonlinear way in a
> pager (by using a pager’s search functionality). The “backend” ‘git
> rev-list’ is easy to write scripts with, also because of its simple
> input and output.
>
> If your program requires input from the user, how will it paginate its
> output? Most pagers expect the standard input to be available for
> input from the user.
>
> One approach (I will not say it is a good one) to the problem of
> ambiguous origins for a line is to blame _both_ parents. That is,
> start following both lines of history in your revision walking.
> Perhaps higher-level tools like ‘git log --graph’ and gitk could
> visually represent the branched history you are showing.
>
> Another approach is to just choose one parent automatically: for
> example, prefer the first parent, or assign some score representing
> the relatedness of each parent and choose the most related one.
Both the approach is very precious for me. I think maybe I will
propose the first one in my real proposal to Git, thanks a lot! You
really help my too much! Thanks!
Regards!
Bo
^ permalink raw reply [relevance 4%]
* Re: GSoC draft proposal: Line-level history browser
@ 2010-03-24 2:39 4% ` Bo Yang
0 siblings, 0 replies; 200+ results
From: Bo Yang @ 2010-03-24 2:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, gitzilla, Alex Riesen, git
HI,
On Wed, Mar 24, 2010 at 2:57 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> If you can make a heuristic along these lines this work well, I think it
> would be great. I imagine it might work very well for commits that made
> nice, small changes (like many of those in git.git). Jakub pointed out
> some of the difficulties, and I like to hope your idea of “when in doubt,
> include more lines” may work well in many cases in git.git still.
>
> Good luck, and thank you for taking my crazy ideas seriously. :)
>
> Regards,
> Jonathan
>
> [1] See v1.4.4-rc1~2 (Merge branch 'jc/pickaxe', 2006-11-07) and the
> commits preceding it. About that series, Junio wrote:
>
> Actually the plan is to make it do _true_ pickaxe,
> although it will most likely end up either in dustbin or
> replace blame.
>
> It replaced blame.
>
> I am not actually sure, but I assume “true pickaxe” refers to the
> goals described in <http://gitster.livejournal.com/35628.html>
> and the linked-to message.
I have looked over the article and the message from Linus, it really
help me very much. The message and article pointed out most of the
things a line level tool should do, and I am happy to find that it is
similar with my proposal. :) Thanks again for your precious advice and
I think I can come up a better proposal, now. Thanks!
Regards!
Bo
^ permalink raw reply [relevance 4%]
* the careless committer and fear of commitment (rebase -i vs add -p)
@ 2010-03-30 5:02 4% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2010-03-30 5:02 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Daniel Thomas, Git Mailing List
Avery Pennarun wrote:
> I generally just make a temporary commit
> with "git commit", then revise it using "git commit --amend" over
> time.
>
> Or else I make a series of commits, then *later* squash them all
> together using 'git merge --squash' or 'git rebase -i'.
>
> It seems like the suggested feature would encourage people to do it
> the "wrong" way (not creating temporary commits, thus making it easy
> to make a mistake and blow things away) just because they aren't aware
> of the above options.
>
> Is there a reason that these methods don't work for you?
I like ‘git diff --cached’ and ‘git diff’ to show the entire list
of staged and unstaged changes. I don’t consider this “wrong” at all.
Generally, once something becomes precious enough to be worth keeping,
it is already in presentable form and I can come up with an appropriate
commit message. I understand that other people work differently; this
is just my personal preference.
I also use the stash heavily, which maybe mitigates the “content could
be blown away with a simple rm -f” problem.
You might also be interested in Pasky’s analysis at
http://thread.gmane.org/gmane.comp.version-control.git/138641/focus=138672
Cheers,
Jonathan
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/2] Use git_open_noatime when accessing pack data
@ 2010-11-04 5:04 4% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2010-11-04 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Judging from these three use cases, readonly open()s to the worktree
>> should indeed use noatime, but open()s of .git/config, say, should
>> not. Hmm.
>
> Why not, when you are talking about readonly open?
A .git/config frequently accessed by git is being used, so tmpwatch
shouldn't delete it. (Meanwhile, a worktree frequently accessed by
git is not precious on that account, and letting git touch the atime
there might mask more useful information about when other programs
touched the files.)
But that is all very fuzzy to me. I tend to mount noatime except on
/usr (for popularity-contest).
I guess I should put it another way. What if anything does readonly
have to do with O_NOATIME? Why shouldn't we always use O_NOATIME?
Why should the operating system provide atime at all?
^ permalink raw reply [relevance 4%]
* Re: [PATCH] git-rebase--interactive.sh: Add new command "shell"
@ 2010-11-08 18:31 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2010-11-08 18:31 UTC (permalink / raw)
To: Yann Dirson
Cc: Jonathan Nieder, Matthieu Moy, Eric Raible, Yann Dirson, kevin,
git
Yann Dirson <ydirson@free.fr> writes:
> # e, edit = use commit (if specified) but pause to amend/examine/test
When an end user is given
pick one
pick two
pick three
...
and told the above, would it be crystal clear that, if he changed the insn
sheet to
pick one
edit
pick three
...
then he will _lose_ the change made by foo, or will the user come back
here and complain that a precious change "two" is lost and it is git's
fault?
^ permalink raw reply [relevance 4%]
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)
@ 2010-12-06 7:29 4% ` Yann Dirson
0 siblings, 0 replies; 200+ results
From: Yann Dirson @ 2010-12-06 7:29 UTC (permalink / raw)
To: gitster; +Cc: git list
>> On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote:
>>> * kb/diff-C-M-synonym (2010-11-29) 1 commit
>>> - diff: add --detect-copies-harder as a synonym for
>>> --find-copies-harder
>>>
>>> Will merge to 'next' soon.
>>
>> If we go this way, don't we want to deprecate --find-copies-harder as
>> well ?
>
>Why?
>
>We are being nice to people who did not know --find-copies-harder but
>learned the --detect-renames long name before learning it, which by
>definition is are people because the long names have been there only for
>the last few months; they may expect "detect" to work there. That is
>the sole purpose of the additional synonym.
But then, why not simply use --find-renames (since --detect-renames has
luckily not been released ontl the masses yet), and avoid making similar-usage
opts dissimilar and then adding a synonym just to make them similar the other
way ?
IOW, we already have tons of options everywhere, let's not just add clutter.
We'll end up here with those people used to using --detect-copies-harder willing
shell completion; that will just add one more item to the list we get after
"--<TAB>", and it will eat precious screen space for pretty much nothing.
Just my 0.02€...
--
Yann Dirson - Bertin Technologies
^ permalink raw reply [relevance 4%]
* Re: Network problems during "git svn dcommit"
@ 2010-12-27 0:57 4% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2010-12-27 0:57 UTC (permalink / raw)
To: Josef Wolf; +Cc: git
Josef Wolf wrote:
> I am using git-svn to track a subversion repository. This used to work
> fine so far. But today, I got a network outage during a "git svn dcommit"
> operation.
[...]
> Any hints how to fix the situation?
Yes.
To fix your repository:
1. make backups!
2. back out the bad commit so it is not visible with "gitk --all"
(something like
git reset --keep HEAD^
git push . HEAD:refs/remotes/svn/Trunk
)
3. "rm -fr .git/svn/". Note: this will delete your unhandled.log!
Restore it from backup if you consider it precious.
4. "git svn fetch; git svn rebase"
To fix "git svn", see [1].
Hope that helps,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/136510
^ permalink raw reply [relevance 4%]
* Re: "git add -u" broken in git 1.7.4?
@ 2011-02-10 7:46 4% ` Johannes Sixt
0 siblings, 0 replies; 200+ results
From: Johannes Sixt @ 2011-02-10 7:46 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, SZEDER Gábor, Matthieu Moy,
Sebastian Pipping, Git ML
Am 2/10/2011 0:46, schrieb Jeff King:
> The current behavior is:
>
> add: error (and suggest "git add .")
> add -u: relative
> add -A: relative
> add -i: full-tree
> add -p: full-tree
> archive: relative
> checkout: full-tree (e.g., "git checkout -f")[1]
> checkout-index: n/a (only checks out arguments)
> clean: relative
> commit -a: full-tree[2]
> diff: full-tree
> diff-files: full-tree
> grep: relative
> ls-files: relative
> ls-tree: relative[3]
> status: shows full-tree, relative by default, absolute
> with status.relativePaths
> reset --hard: full-tree[4]
> log/show/etc: full-tree[5]
> blame: error[6]
rerere forget: relative
It is a destructive command, and the rerere cache is precious, IMO.
Therefore, I'd vote to make 'git rerere forget' without a pathspec an error.
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: non-empty index with git commit -a
@ 2011-02-16 8:18 4% ` Sverre Rabbelier
0 siblings, 1 reply; 200+ results
From: Sverre Rabbelier @ 2011-02-16 8:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, Git List, Jakub Narebski
Heya,
On Wed, Feb 16, 2011 at 03:20, Jonathan Nieder <jrnieder@gmail.com> wrote:
> If I remember the discussion[1] correctly, by requiring a separate
> add -u step (or commit -f -a) if the "I don't trust my fingers"
> configuration is enabled.
That would definitely work for me. The question then is, should git
consider the index precious by default, or not? That is, should that
value default to true in 1.8?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 4%]
* Re: non-empty index with git commit -a
2011-02-16 10:28 4% ` Matthieu Moy
@ 2011-02-16 9:58 4% ` Sverre Rabbelier
2011-02-16 10:06 4% ` Jeff King
1 sibling, 1 reply; 200+ results
From: Sverre Rabbelier @ 2011-02-16 9:58 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, Git List, Jakub Narebski
Heya,
On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:
> So? Your question was whether index state is precious. If it's precious,
> shouldn't we be keeping a history of it?
I don't think it's quite _that_ precious, but the only operation that
I regularly use that can blow away my carefully constructed index as
side effect of doing something else is `git commit -a`.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 4%]
* Re: non-empty index with git commit -a
2011-02-16 9:58 4% ` Sverre Rabbelier
@ 2011-02-16 10:06 4% ` Jeff King
2011-02-16 14:41 4% ` Michael J Gruber
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2011-02-16 10:06 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Jonathan Nieder, Git List, Jakub Narebski
On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:
> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:
> > So? Your question was whether index state is precious. If it's precious,
> > shouldn't we be keeping a history of it?
>
> I don't think it's quite _that_ precious, but the only operation that
> I regularly use that can blow away my carefully constructed index as
> side effect of doing something else is `git commit -a`.
OK, so how precious is it? :)
If you want to have an option that specifically prevents the "git commit
-a" muscle memory thing, then go for it. I'm guessing it is the most
common "oops" one. Even with an index reflog, you might want it on top.
But it just seems silly to me to not protect at the same time against
the other ways you can lose state from the index.
-Peff
^ permalink raw reply [relevance 4%]
* Re: non-empty index with git commit -a
@ 2011-02-16 10:28 4% ` Matthieu Moy
2011-02-16 9:58 4% ` Sverre Rabbelier
1 sibling, 0 replies; 200+ results
From: Matthieu Moy @ 2011-02-16 10:28 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Jonathan Nieder, Git List, Jakub Narebski
Jeff King <peff@peff.net> writes:
> So? Your question was whether index state is precious. If it's precious,
> shouldn't we be keeping a history of it?
If it's really precious, it probably means you should be commit
--amend instead. You'd get the reflog, and essentially the same
functionalities.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [relevance 4%]
* Re: non-empty index with git commit -a
2011-02-16 10:06 4% ` Jeff King
@ 2011-02-16 14:41 4% ` Michael J Gruber
0 siblings, 0 replies; 200+ results
From: Michael J Gruber @ 2011-02-16 14:41 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Jonathan Nieder, Git List, Jakub Narebski
Jeff King venit, vidit, dixit 16.02.2011 11:06:
> On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote:
>
>> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote:
>>> So? Your question was whether index state is precious. If it's precious,
>>> shouldn't we be keeping a history of it?
>>
>> I don't think it's quite _that_ precious, but the only operation that
>> I regularly use that can blow away my carefully constructed index as
>> side effect of doing something else is `git commit -a`.
>
> OK, so how precious is it? :)
Maybe it's a bit precious, but not overly...
>
> If you want to have an option that specifically prevents the "git commit
> -a" muscle memory thing, then go for it. I'm guessing it is the most
> common "oops" one. Even with an index reflog, you might want it on top.
>
> But it just seems silly to me to not protect at the same time against
> the other ways you can lose state from the index.
>
> -Peff
so that keeping one backup would be enough? I.e. an automated way of
doing "cp index index.bak" before an index update and some "reset"
incarnation to revive the copy?
Michael
^ permalink raw reply [relevance 4%]
* Re: git rebase --continue automatic --skip?
@ 2011-04-09 13:03 4% ` Peter Baumann
0 siblings, 0 replies; 200+ results
From: Peter Baumann @ 2011-04-09 13:03 UTC (permalink / raw)
To: Jeff King; +Cc: skillzero, Martin von Zweigbergk, Git Mailing List
On Fri, Apr 08, 2011 at 08:03:51PM -0400, Jeff King wrote:
> On Fri, Apr 08, 2011 at 01:30:01PM -0700, skillzero@gmail.com wrote:
>
> > Is there a way to make git rebase --continue automatically do a --skip
> > if a conflict resolution ends up not needing the patch? Normally, git
> > rebase will just silently skip a patch if it's not needed, but if a
> > patch results in a conflict and I use git mergetool and end up
> > deleting all the changes, git rebase --continue stops and makes me
> > explicitly use --skip.
>
> This is something I have often wanted, too. The patch would look
> something like this:
>
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 7a54bfc..cec15ae 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -319,6 +319,11 @@ continue)
> echo "mark them as resolved using git add"
> exit 1
> }
> + if git diff-index --quiet HEAD --; then
> + test -z "$GIT_QUIET" &&
> + echo >&2 "Commit has no changes -- skipping"
> + action=skip
> + fi
> read_basic_state
> run_specific_rebase
> ;;
>
> that is based on what is in "next", as there has been a lot of cleanup
> in git-rebase recently[1].
>
> I put it in rebase and not straight into "git am", as I'm not sure that
> "am" would want to share the same behavior. I'm not sure why we haven't
> done this up until now. Maybe there is some corner case I'm not thinking
> of where the user would want to do something besides skip when we hit
> this situation. I dunno.
>
This was mentioned before on the list (sorry, don't have a reference,
but it was a long time ago). AFAIR the reason it wasn't implemented yet is that
you will lose the commit message, which might contain precious information.
But with reflogs this shouldn't be a problem anymore.
-Peter
> Potentially this should also go into the rebase--am specific script. I
> haven't really thought it through.
>
> -Peff
>
> [1] I hadn't really been following Martin's rebase cleanup, but it is
> _way_ nicer to look at these days.
^ permalink raw reply [relevance 4%]
* Re: [PATCH 0/9] magic pathspec updates
@ 2011-05-11 12:11 4% ` Nguyen Thai Ngoc Duy
0 siblings, 0 replies; 200+ results
From: Nguyen Thai Ngoc Duy @ 2011-05-11 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, May 11, 2011 at 12:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Note that no such command exists in our vocabulary today, so you need
> to imagine "git local-log" that acts like "git log" but by default
> shows history simplified to explain only the subdirectory you are
> currently in, or something.
>
> Such an application can easily notice that argv[] has only a lone ":"
> left and do the same thing it does when there is no pathspec, without
> affecting other (existing) users of get_pathspec().
Hmm.. if ":" (the semantics) is only used in few commands, perhaps an
option would be better than the cryptic ":".
> I am leaning toward ripping the lone ":" support from the code in
> "next". I would also remove ":(icase)" from "next". It was only meant
> to be a POC to show how far we could go only by futzing get_pathspec()
> function, and was never meant to be a serious implementation of the
> feature. It should be re-done after we do deeper conversion and use
> the "struct pathspec" interface not "char **" interface.
OK. But reserve the lone ":" syntax. It's precious. We may have a use
case for it some day.
--
Duy
^ permalink raw reply [relevance 4%]
* Re: Re* git clean --exclude broken?
@ 2011-08-27 23:54 4% ` Pete Wyckoff
0 siblings, 0 replies; 200+ results
From: Pete Wyckoff @ 2011-08-27 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Todd Rinaldo
gitster@pobox.com wrote on Thu, 25 Aug 2011 11:29 -0700:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > The documentation and the implementation of "git clean" is quite confused.
> > ...
>
> So here is a patch to fix the confusion.
>
> It does not add a new "--except=C" I alluded to, but at least it should
> be the right first step to make the document clearly describe what the
> existing option does.
>
> -- >8 --
> Subject: [PATCH] Documentation: clarify "git clean -e <pattern>"
>
> The current explanation of -e can be misread as allowing the user to say
>
> I know 'git clean -XYZ' (substitute -XYZ with any option and/or
> parameter) will remove paths A, B, and C, and I want them all removed
> except for paths matching this pattern by adding '-e C' to the same
> command line, i.e. 'git clean -e C -XYZ'.
>
> But that is not what this option does. It augments the set of ignore rules
> from the command line, just like the same "-e <pattern>" argument does
> with the "ls-files" command (the user could probably pass "-e \!C" to tell
> the command to clean everything the command would normally remove, except
> for C).
>
> It also fixes small style nit in the parameter to add_exclude() call. The
> current code only works because EXC_CMDL happens to be defined as 0.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-clean.txt | 6 +++---
> builtin/clean.c | 5 ++++-
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index 974e04e..a7a18e3 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -47,9 +47,9 @@ OPTIONS
>
> -e <pattern>::
> --exclude=<pattern>::
> - Specify special exceptions to not be cleaned. Each <pattern> is
> - the same form as in $GIT_DIR/info/excludes and this option can be
> - given multiple times.
> + In addition to what are found in .gitignore (per directory) and
> + $GIT_DIR/info/exclude, also consider these patterns to be in the
> + set of the ignore rules in effect.
>
> -x::
> Don't use the ignore rules. This allows removing all untracked
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 75697f7..3782718 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -76,6 +76,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>
> if (ignored && ignored_only)
> die(_("-x and -X cannot be used together"));
> + if (ignored && exclude_list.nr)
> + die(_("adding exclude with -e and ignoring it with -x is crazy"));
This breaks one of my use cases for git clean.
We have "precious" files that are listed in .gitignore so that
they don't show up in "git status" output. They're not part of
the repository, but special per-user per-workspace configuration
settings that are required to build the code.
There's plenty of other stuff in .gitignore that should be
deleted. So we invoke:
git clean -dqfx -e .magic_file -e "Magic*"
It's been discussed on the list a couple of times that a separate
category for files that I want to ignore, but do not want to
have cleaned, would fill this gap.
-- Pete
> if (!show_only && !force) {
> if (config_set)
> @@ -98,7 +100,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> setup_standard_excludes(&dir);
>
> for (i = 0; i < exclude_list.nr; i++)
> - add_exclude(exclude_list.items[i].string, "", 0, dir.exclude_list);
> + add_exclude(exclude_list.items[i].string, "", 0,
> + &dir.exclude_list[EXC_CMDL]);
>
> pathspec = get_pathspec(prefix, argv);
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [relevance 4%]
* Re: What should "git fetch origin +next" should do?
@ 2011-10-17 18:34 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2011-10-17 18:34 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> I think the exact same confusion exists. I told git to update 'next'
> from origin, but it didn't touch refs/remotes/origin/next.
Except that you didn't tell git to *update* the remote tracking branch for
'next'; you merely told it to fetch 'next' at the remote.
> ... But I suspect that is not how many git users think of it.
I am inclined to agree that it might be the case; see my other message in
this thread.
> We've discussed this before, of course:
>
> http://thread.gmane.org/gmane.comp.version-control.git/127163/focus=127215
Yes, you brought up the "remote state as of the time I told git to record
it is a precious piece of information" issue, and I share the reasoning,
hence I am somewhat torn.
We might be better off biting the bullet and do the "rewrite a command
line colon-less refspec using a matching configured refspec iff exists"
and defer the history of remote tracking branches to its reflog in the
longer term.
^ permalink raw reply [relevance 4%]
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
@ 2011-11-21 15:44 4% ` Bertrand BENOIT
2011-11-27 10:13 4% ` Nguyen Thai Ngoc Duy
1 sibling, 0 replies; 200+ results
From: Bertrand BENOIT @ 2011-11-21 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, Johannes Sixt, Taylor Hedberg, git
2011/11/21 Junio C Hamano <gitster@pobox.com>:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> If you want to keep this accident (which is a bug to me), you may want
>> to add the reason: callers to unpack_trees() are supposed to also
>> setup exclude rules in .git/info/exclude before calling
>> unpack_trees(), which they don't.
>>
>> So .git/info/exclude is entirely dismissed.
>
> Ohh, thanks for this and also for digging this through in your other
> message.
>
> I think it is the right thing to do to make sure .gitignore and
> info/exclude behave the same way regardless of the original issue in this
> topic.
>
> In the medium term, I think one reasonable way forward solving the "TODO
> that used to be tracked but now untracked and ignored" issue is to
> introduce "info/exclude-override" that comes between command line and
> in-tree patterns. The info/exclude file is designed as the fallback
> definition to be used when all other sources are too lax, and comes near
> the precedence stack; the "TODO" situation however calls for an override
> that is stronger than the in-tree patterns.
>
> In the longer term, we should carefully determine if we need "precious" in
> the first place. The last time this was brought up there were people who
> argued they are OK with having to remove the ignored file by hand when
> checking out another branch (i.e. we switch the semantics of "ignored" so
> that they are "not tracked but all precious").
>
> I think it matters in two cases.
>
> (1) If you change an untracked "cruft" file on branch A into a directory
> with tracked files in it on another branch B. If you are on branch A,
> have that "cruft" file (perhaps it is a build product after running
> "make"), and try to checkout branch B, such an updated "git checkout"
> will start erroring out telling you that "cruft" will be lost.
>
> (2) If you have a directory on branch A, underneath of which there are
> untracked "cruft" files (e.g. think "build/" directory that is full
> of "*.o" files and ".gitignore" to mark object files as ignored but
> is otherwise empty), and another branch B that has the same path as a
> file. If you are on branch A, have "cruft" files in that directory,
> and try to checkout branch B, such an updated "git checkout" will
> start erroring out telling you that "cruft" will be lost.
>
> If people are OK with such a behaviour, we can do without "precious".
>
> Otherwise we would need to update excluded() in dir.c to return tristate
> (ignored, precious or unspecified) instead of the current boolean (ignored
> or unspecified), examine and decide for each caller what they want to do
> to "precious" files.
IMO, as user, I think that erroring out telling you that 'cruft' will
be lost, is enough to avoid data loss.
However, in addition the tristate system (with a dedicated syntax in
.gitattributes and/or .gitignore files) would give more freedom,
without having to move 'untracked but precious' files between each
updated 'git checkout'.
^ permalink raw reply [relevance 4%]
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
2011-11-21 15:44 4% ` Bertrand BENOIT
@ 2011-11-27 10:13 4% ` Nguyen Thai Ngoc Duy
1 sibling, 1 reply; 200+ results
From: Nguyen Thai Ngoc Duy @ 2011-11-27 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> In the medium term, I think one reasonable way forward solving the "TODO
> that used to be tracked but now untracked and ignored" issue is to
> introduce "info/exclude-override" that comes between command line and
> in-tree patterns. The info/exclude file is designed as the fallback
> definition to be used when all other sources are too lax, and comes near
> the precedence stack; the "TODO" situation however calls for an override
> that is stronger than the in-tree patterns.
Short term, should we allow an option to disregard ignored status
(i.e. all files are precious)? Something like [2/2]
[1/2] checkout,merge: loosen overwriting untracked file check based on
info/exclude
[2/2] checkout,merge: disallow overwriting ignored files with
--no-overwrite-ignore
--
Duy
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/2] checkout,merge: loosen overwriting untracked file check based on info/exclude
@ 2011-11-29 18:17 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2011-11-29 18:17 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Sixt, Taylor Hedberg, Bertrand BENOIT
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Back in 1127148 (Loosen "working file will be lost" check in
> Porcelain-ish - 2006-12-04), git-checkout.sh learned to quietly
> overwrite ignored files. Howver the code only took .gitignore files
> into account.
v1.5.3.5-721-g039bc64 also tried to make it harder to make this kind of
mistake, and forgot to spot it in git-checkout.sh which was a bit
unfortunate.
Thanks. I think both patches make sense, and especially 2/2 opens the door
to possibly make ignored ones automatically precious.
^ permalink raw reply [relevance 4%]
* Re: Roadmap for 1.7.9
@ 2011-12-06 11:16 4% ` Nguyen Thai Ngoc Duy
0 siblings, 0 replies; 200+ results
From: Nguyen Thai Ngoc Duy @ 2011-12-06 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Tue, Dec 6, 2011 at 3:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I expect the following will not make much progress without further
> discussion:
>
> * Ignored vs Precious (Nguyen Thai Ngoc Duy)
I'm working on adding --exclude-standard and --exclude-from to
read-tree. Apart from that I don't plan on supporting precious files
because I don't use them.
--
Duy
^ permalink raw reply [relevance 4%]
* Re: Working directory managment
@ 2012-03-28 15:39 4% ` Anjib Mulepati
0 siblings, 0 replies; 200+ results
From: Anjib Mulepati @ 2012-03-28 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I am sorry if I haven't put my follow up question in proper place. It
was on top. My question was
So these removed or replaced is done automatically or as I understood we
do merge and and see conflict and do changes as per necessary?
i don't want to waste someone precious time but I am reading book and
searching my own in internet to clear my confusion. That is not clear
all time so that's why I am using this forum. I am reading all replies
and trying to get basic concept as I go.
Thanks All
Anjib
On 3/28/2012 11:13 AM, Junio C Hamano wrote:
> Anjib Mulepati<anjibcs@hotmail.com> writes:
>
>> What does it mean by this " Files in this directory are often removed
>> or replaced by Git as you switch branches"?
> Don't you already have an answer from me in the message you are responding
> to, which you quoted but perhaps you didn't read?
>
>
>
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/6] Remove i18n legos in notifying new branch tracking setup
@ 2012-05-31 14:00 4% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2012-05-31 14:00 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, Ævar Arnfjörð Bjarmason,
Jiang Xin
Nguyễn Thái Ngọc Duy wrote:
> Not sure if it's the right way to fix these though. For example, while
> 1/1 looks very good from i18n perspective, code-wise it's quite ugly.
> Grouping format strings in array also prevents gcc from checking
> correct parameters, I think.
[...]
> --- a/branch.c
> +++ b/branch.c
> @@ -74,25 +74,43 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
[...]
> - strbuf_addstr(&key, origin ? "remote" : "local");
> -
> - /* Are we tracking a proper "branch"? */
> - if (remote_is_branch) {
> - strbuf_addf(&key, " branch %s", shortname);
> - if (origin)
> - strbuf_addf(&key, " from %s", origin);
> + if (rebasing) {
> + if (remote_is_branch) {
> + if (origin)
> + printf("Branch %s set up to track remote branch %s from %s by rebasing.\n",
> + local, shortname, origin);
> + else
[...]
> + } else {
> + if (origin)
[...]
> + }
> + } else {
> + if (remote_is_branch) {
[...]
I think a table-driven version of this switchboard would be much
easier to read, even if it would hurt gcc's -Wformat checking. If the
-Wformat safety is too precious to lose, would something like the
following work?
switch (tracking_msg_flags) {
case REBASING | REMOTE_IS_BRANCH | ORIGIN:
printf(_("Branch %s set up to track remote branch %s ..."),
...
break;
case REBASING | REMOTE_IS_BRANCH:
printf(_(...
^ permalink raw reply [relevance 4%]
* Re: git bisect/checkout and changes to .gitignore
@ 2012-06-22 10:31 4% ` Johannes Sixt
2012-06-22 17:42 4% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Johannes Sixt @ 2012-06-22 10:31 UTC (permalink / raw)
To: Chris Angelico; +Cc: git
Am 6/22/2012 9:51, schrieb Chris Angelico:
> At my workplace we use git to manage all of our source code. Every now
> and then, we decide that some particular file oughtn't to be
> git-managed, and add it into .gitignore and remove it from the
> repository (for instance, configuration files that become
> per-developer).
>
> Is there a way to checkout an old version of the repository (before
> the file was added to .gitignore), then return to the current state,
> without destroying these sorts of files? Currently, checking out the
> old version quietly "takes control" of the file, and then checking out
> a newer one deletes it.
>
> I've read through the man pages for 'git checkout' and 'gitignore' and
> searched the one for 'git config' (it's a little large to read all
> of), without seeing an option to preserve files on checkout. Is there
> a way to do this, and if so, where can I find it?
Files mentioned in .gitignore are considered garbage. But your file is
precious, hence, you should not list it in .gitignore.
Here is a thread that is worthwhile to read. I posted a patch
http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185733
but it was dismissed, see
http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185746
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: git bisect/checkout and changes to .gitignore
2012-06-22 10:31 4% ` Johannes Sixt
@ 2012-06-22 17:42 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2012-06-22 17:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Chris Angelico, git
Johannes Sixt <j.sixt@viscovery.net> writes:
> Here is a thread that is worthwhile to read. I posted a patch
>
> http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185733
>
> but it was dismissed, see
>
> http://thread.gmane.org/gmane.comp.version-control.git/185724/focus=185746
Thanks.
Two thoughts and a half.
- For people who do not want to read the above, the patch in the
former was not a change to the code, but was a demonstration to
exploit a bug in .git/ignore/exclude handling.
- The latter message above outlined a future direction to properly
handle "ignored" vs "precious" distinction.
- There probably are other "here is a way forward" messages in the
list archive whose visions haven't been materialized. Is anybody
collecting these? I suspect that such a collection would be far
more useful than a typical bug tracker that nobody looks at.
^ permalink raw reply [relevance 4%]
* Re: Minor bug in git branch --set-upstream-to adding superfluous branch section to config
@ 2013-03-29 17:20 4% ` Thomas Rast
0 siblings, 0 replies; 200+ results
From: Thomas Rast @ 2013-03-29 17:20 UTC (permalink / raw)
To: Jeff King; +Cc: Phil Haack, git
Jeff King <peff@peff.net> writes:
> I think what happens is that the config editor runs
> through the files linearly, munging whatever lines necessary for the
> requested operation, and leaving everything else untouched (as it must,
> to leave comments and whitespace intact). But it does not keep a
> look-behind buffer to realize that a section name is now obsolete (which
> we don't know until we get to the next section, or to EOF). In the worst
> case, this buffer can grow arbitrarily large, like:
>
> [foo]
> # the above section is now empty
> # but we have to read through all of
> # these comments to actually
> # realize it
> [bar]
If we treat this case as having a bunch of comments that make the
section non-empty, then we both avoid needing an arbitrarily large
lookbehind and deleting the user's precious comments...
I.e. the rule would be that we only delete the section if there is
nothing but whitespace until the next section header.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history
@ 2013-10-30 12:01 4% ` Johannes Sixt
0 siblings, 0 replies; 200+ results
From: Johannes Sixt @ 2013-10-30 12:01 UTC (permalink / raw)
To: Nicolas Cornu, git; +Cc: paulus
Am 10/30/2013 11:58, schrieb Nicolas Cornu:
> This scrollbar is not optional and is useful if there is a lot of tags or
> branches.
If this is the "only" case where the scrollbar is useful, i.e., it would
be handy only once every other week, then it is better to remember that
you can pan around in the window by moving the mouse with the middle mouse
button held down. Vertical screen estate in the commit history pane is too
precious to waste for a scrollbar that is useless most of the time.
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: [RFC] git checkout $tree -- $path always rewrites files
@ 2014-11-09 9:42 4% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2014-11-09 9:42 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Junio C Hamano, Git Mailing List
On Sat, Nov 08, 2014 at 08:19:21AM -0800, Martin von Zweigbergk wrote:
> > What should:
> >
> > git checkout HEAD -- some-new-path
> >
> > do in that case? With the current code, it actually barfs, complaining
> > that nothing matched some-new-path (because it is not part of HEAD, and
> > therefore we don't consider it at all), and aborts the whole operation.
> > I think we would want to delete some-new-path in that case, too.
>
> I don't think we'd want it to be deleted. I would view 'git reset
> --hard' as the role model here, and that command (without paths) would
> not remove the file. And applying it to a path should not change the
> behavior, just restrict it to the paths, right?
Are you sure about "git reset" here? If I do:
git init
echo content >file && git add file && git commit -m base
echo modified >file
echo new >some-new-path
git add file some-new-path
git reset --hard
then we delete some-new-path (it is not untracked, because the index
knows about it). That makes sense to me. I.e., we treat it with the same
"preciousness" whether it is named explicitly or not.
-Peff
^ permalink raw reply [relevance 4%]
* [BUG] interactive rebase loses instruction sheet when aborting to avoid overwriting files
[not found] <1009315412.367253372.1418981868176.JavaMail.root@zimbra39-e7.priv.proxad.net>
@ 2014-12-19 9:42 4% ` ydirson
0 siblings, 0 replies; 200+ results
From: ydirson @ 2014-12-19 9:42 UTC (permalink / raw)
To: git list; +Cc: dirson, ydirson
[using v2.1.3]
When using "rebase -i" and the working dir contains untracked files that are present
in the new base, we correctly get a "would be overwritten by checkout" error, but then
the whole rebase interrupts the (long) listing of the incriminated files in the middle
of a line and terminates with:
Aborting
could not detach HEAD
And consequently we are not rebasing any more, and the precious instruction sheet has been
lost.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v5 2/6] help.c: output the typical Git workflow
@ 2015-05-11 6:24 4% ` Eric Sunshine
0 siblings, 0 replies; 200+ results
From: Eric Sunshine @ 2015-05-11 6:24 UTC (permalink / raw)
To: Sébastien Guimmara; +Cc: Git List
On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
<sebastien.guimmara@gmail.com> wrote:
> 'git help' shows common commands in alphabetical order:
>
> The most commonly used git commands are:
> add Add file contents to the index
> bisect Find by binary search the change that introduced a bug
> branch List, create, or delete branches
> checkout Checkout a branch or paths to the working tree
> clone Clone a repository into a new directory
> commit Record changes to the repository
> [...]
>
> without any indication of how commands relate to high-level
> concepts or each other. Revise the output to explain their relationship
> with the typical Git workflow:
>
> The typical Git workflow includes:
>
> * start a working area (see also: git help tutorial):
> clone Clone a repository into a new directory
> init Create an empty Git repository or reinitialize [...]
In practice, I find the indented bulleted header items somewhat
unsightly. More importantly, indenting them wastes precious horizontal
screen real-estate (for those of who use 80-column terminals). Since
the headers are already distinguished by being bulleted, you could
easily drop the indentation; and then reduce the indentation of the
commands themselves.
> * work on the current change (see also: git help everyday):
> add Add file contents to the index
> reset Reset current HEAD to the specified state
>
> * examine the history and state (see also: git help revisions):
> log Show commit logs
> status Show the working tree status
>
> [...]
>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>
> ---
> diff --git a/help.c b/help.c
> index 2072a87..1df205f 100644
> --- a/help.c
> +++ b/help.c
> @@ -218,6 +218,18 @@ void list_commands(unsigned int colopts,
> }
> }
>
> +int cmd_group_cmp(const void *elem1, const void *elem2)
> +{
> + const struct cmdname_help *e1 = elem1;
> + const struct cmdname_help *e2 = elem2;
> +
> + if (e1->group < e2->group)
> + return -1;
> + if (e1->group > e2->group)
> + return 1;
> + return strcmp(e1->name, e2->name);
> +}
> +
> void list_common_cmds_help(void)
> {
> int i, longest = 0;
> @@ -227,9 +239,18 @@ void list_common_cmds_help(void)
> longest = strlen(common_cmds[i].name);
> }
>
> - puts(_("The most commonly used git commands are:"));
> + qsort(common_cmds, ARRAY_SIZE(common_cmds),
> + sizeof(common_cmds[0]), cmd_group_cmp);
> +
> + puts(_("The typical Git workflow includes:"));
> +
> for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
> - printf(" %s ", common_cmds[i].name);
> + if (common_cmds[i].group != current_grp) {
> + printf("\n * %s:\n", _(common_cmd_groups[common_cmds[i].group]));
> + current_grp = common_cmds[i].group;
> + }
> +
> + printf(" %s ", common_cmds[i].name);
> mput_char(' ', longest - strlen(common_cmds[i].name));
> puts(_(common_cmds[i].help));
> }
> --
> 2.4.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3 22/23] worktree: add: auto-vivify new branch when <branch> is omitted
@ 2015-07-07 16:10 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2015-07-07 16:10 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git, Duy Nguyen, Mark Levedahl, Mikael Magnusson
Eric Sunshine <sunshine@sunshineco.com> writes:
>> Which may be something we would want to have a test for, though.
>
> Good idea. How about the following as a squash-in?
Sounds sensible.
At this point we do not have "worktree list", but if we gained that,
we may want to add this as one more postcondition after the failed
"worktree add":
git worktree list >actual &&
! grep precious actual
but that should happen in the series that adds "worktree list" ;-)
> --- 8< ---
> From: Eric Sunshine <sunshine@sunshineco.com>
> Subject: [PATCH] fixup! worktree: add: auto-vivify new branch when <branch> is omitted
>
> ---
> t/t2025-worktree-add.sh | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index 8fe242f..ead8aa2 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -150,4 +150,13 @@ test_expect_success '"add" with <branch> omitted' '
> test_cmp_rev HEAD bat
> '
>
> +test_expect_success '"add" auto-vivify does not clobber existing branch' '
> + test_commit c1 &&
> + test_commit c2 &&
> + git branch precious HEAD~1 &&
> + test_must_fail git worktree add precious &&
> + test_cmp_rev HEAD~1 precious &&
> + test_path_is_missing precious
> +'
> +
> test_done
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4 26/26] introduce "extensions" form of core.repositoryformatversion
@ 2015-10-21 19:40 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2015-10-21 19:40 UTC (permalink / raw)
To: David Turner; +Cc: git, mhagger, Jeff King
David Turner <dturner@twopensource.com> writes:
> From: Jeff King <peff@peff.net>
I just made sure this is bit-for-bit identical with the first of the
two patches I received from Peff and I locally have kept.
Re-reading the two patches again, I do not see a reason why we should
reject them. I'll queue this and the other "precious object" one
separately.
Thanks.
>
> Normally we try to avoid bumps of the whole-repository
> core.repositoryformatversion field. However, it is
> unavoidable if we want to safely change certain aspects of
> git in a backwards-incompatible way (e.g., modifying the set
> of ref tips that we must traverse to generate a list of
> unreachable, safe-to-prune objects).
>
> If we were to bump the repository version for every such
> change, then any implementation understanding version `X`
> would also have to understand `X-1`, `X-2`, and so forth,
> even though the incompatibilities may be in orthogonal parts
> of the system, and there is otherwise no reason we cannot
> implement one without the other (or more importantly, that
> the user cannot choose to use one feature without the other,
> weighing the tradeoff in compatibility only for that
> particular feature).
>
> This patch documents the existing repositoryformatversion
> strategy and introduces a new format, "1", which lets a
> repository specify that it must run with an arbitrary set of
> extensions. This can be used, for example:
>
> - to inform git that the objects should not be pruned based
> only on the reachability of the ref tips (e.g, because it
> has "clone --shared" children)
>
> - that the refs are stored in a format besides the usual
> "refs" and "packed-refs" directories
>
> Because we bump to format "1", and because format "1"
> requires that a running git knows about any extensions
> mentioned, we know that older versions of the code will not
> do something dangerous when confronted with these new
> formats.
>
> For example, if the user chooses to use database storage for
> refs, they may set the "extensions.refbackend" config to
> "db". Older versions of git will not understand format "1"
> and bail. Versions of git which understand "1" but do not
> know about "refbackend", or which know about "refbackend"
> but not about the "db" backend, will refuse to run. This is
> annoying, of course, but much better than the alternative of
> claiming that there are no refs in the repository, or
> writing to a location that other implementations will not
> read.
>
> Note that we are only defining the rules for format 1 here.
> We do not ever write format 1 ourselves; it is a tool that
> is meant to be used by users and future extensions to
> provide safety with older implementations.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/technical/repository-version.txt | 81 ++++++++++++++++++++++++++
> cache.h | 6 ++
> setup.c | 37 +++++++++++-
> t/t1302-repo-version.sh | 38 ++++++++++++
> 4 files changed, 159 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/technical/repository-version.txt
>
> diff --git a/Documentation/technical/repository-version.txt b/Documentation/technical/repository-version.txt
> new file mode 100644
> index 0000000..3d7106d
> --- /dev/null
> +++ b/Documentation/technical/repository-version.txt
> @@ -0,0 +1,81 @@
> +Git Repository Format Versions
> +==============================
> +
> +Every git repository is marked with a numeric version in the
> +`core.repositoryformatversion` key of its `config` file. This version
> +specifies the rules for operating on the on-disk repository data. An
> +implementation of git which does not understand a particular version
> +advertised by an on-disk repository MUST NOT operate on that repository;
> +doing so risks not only producing wrong results, but actually losing
> +data.
> +
> +Because of this rule, version bumps should be kept to an absolute
> +minimum. Instead, we generally prefer these strategies:
> +
> + - bumping format version numbers of individual data files (e.g.,
> + index, packfiles, etc). This restricts the incompatibilities only to
> + those files.
> +
> + - introducing new data that gracefully degrades when used by older
> + clients (e.g., pack bitmap files are ignored by older clients, which
> + simply do not take advantage of the optimization they provide).
> +
> +A whole-repository format version bump should only be part of a change
> +that cannot be independently versioned. For instance, if one were to
> +change the reachability rules for objects, or the rules for locking
> +refs, that would require a bump of the repository format version.
> +
> +Note that this applies only to accessing the repository's disk contents
> +directly. An older client which understands only format `0` may still
> +connect via `git://` to a repository using format `1`, as long as the
> +server process understands format `1`.
> +
> +The preferred strategy for rolling out a version bump (whether whole
> +repository or for a single file) is to teach git to read the new format,
> +and allow writing the new format with a config switch or command line
> +option (for experimentation or for those who do not care about backwards
> +compatibility with older gits). Then after a long period to allow the
> +reading capability to become common, we may switch to writing the new
> +format by default.
> +
> +The currently defined format versions are:
> +
> +Version `0`
> +-----------
> +
> +This is the format defined by the initial version of git, including but
> +not limited to the format of the repository directory, the repository
> +configuration file, and the object and ref storage. Specifying the
> +complete behavior of git is beyond the scope of this document.
> +
> +Version `1`
> +-----------
> +
> +This format is identical to version `0`, with the following exceptions:
> +
> + 1. When reading the `core.repositoryformatversion` variable, a git
> + implementation which supports version 1 MUST also read any
> + configuration keys found in the `extensions` section of the
> + configuration file.
> +
> + 2. If a version-1 repository specifies any `extensions.*` keys that
> + the running git has not implemented, the operation MUST NOT
> + proceed. Similarly, if the value of any known key is not understood
> + by the implementation, the operation MUST NOT proceed.
> +
> +Note that if no extensions are specified in the config file, then
> +`core.repositoryformatversion` SHOULD be set to `0` (setting it to `1`
> +provides no benefit, and makes the repository incompatible with older
> +implementations of git).
> +
> +This document will serve as the master list for extensions. Any
> +implementation wishing to define a new extension should make a note of
> +it here, in order to claim the name.
> +
> +The defined extensions are:
> +
> +`noop`
> +~~~~~~
> +
> +This extension does not change git's behavior at all. It is useful only
> +for testing format-1 compatibility.
> diff --git a/cache.h b/cache.h
> index 1d8a051..4b03cb3 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -696,7 +696,13 @@ extern char *notes_ref_name;
>
> extern int grafts_replace_parents;
>
> +/*
> + * GIT_REPO_VERSION is the version we write by default. The
> + * _READ variant is the highest number we know how to
> + * handle.
> + */
> #define GIT_REPO_VERSION 0
> +#define GIT_REPO_VERSION_READ 1
> extern int repository_format_version;
> extern int check_repository_format(void);
>
> diff --git a/setup.c b/setup.c
> index 2b64cbb..0c29469 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -5,6 +5,7 @@
> static int inside_git_dir = -1;
> static int inside_work_tree = -1;
> static int work_tree_config_is_bogus;
> +static struct string_list unknown_extensions = STRING_LIST_INIT_DUP;
>
> /*
> * The input parameter must contain an absolute path, and it must already be
> @@ -349,10 +350,23 @@ void setup_work_tree(void)
>
> static int check_repo_format(const char *var, const char *value, void *cb)
> {
> + const char *ext;
> +
> if (strcmp(var, "core.repositoryformatversion") == 0)
> repository_format_version = git_config_int(var, value);
> else if (strcmp(var, "core.sharedrepository") == 0)
> shared_repository = git_config_perm(var, value);
> + else if (skip_prefix(var, "extensions.", &ext)) {
> + /*
> + * record any known extensions here; otherwise,
> + * we fall through to recording it as unknown, and
> + * check_repository_format will complain
> + */
> + if (!strcmp(ext, "noop"))
> + ;
> + else
> + string_list_append(&unknown_extensions, ext);
> + }
> return 0;
> }
>
> @@ -363,6 +377,8 @@ static int check_repository_format_gently(const char *gitdir, int *nongit_ok)
> config_fn_t fn;
> int ret = 0;
>
> + string_list_clear(&unknown_extensions, 0);
> +
> if (get_common_dir(&sb, gitdir))
> fn = check_repo_format;
> else
> @@ -380,16 +396,31 @@ static int check_repository_format_gently(const char *gitdir, int *nongit_ok)
> * is a good one.
> */
> git_config_early(fn, NULL, repo_config);
> - if (GIT_REPO_VERSION < repository_format_version) {
> + if (GIT_REPO_VERSION_READ < repository_format_version) {
> if (!nongit_ok)
> die ("Expected git repo version <= %d, found %d",
> - GIT_REPO_VERSION, repository_format_version);
> + GIT_REPO_VERSION_READ, repository_format_version);
> warning("Expected git repo version <= %d, found %d",
> - GIT_REPO_VERSION, repository_format_version);
> + GIT_REPO_VERSION_READ, repository_format_version);
> warning("Please upgrade Git");
> *nongit_ok = -1;
> ret = -1;
> }
> +
> + if (repository_format_version >= 1 && unknown_extensions.nr) {
> + int i;
> +
> + if (!nongit_ok)
> + die("unknown repository extension: %s",
> + unknown_extensions.items[0].string);
> +
> + for (i = 0; i < unknown_extensions.nr; i++)
> + warning("unknown repository extension: %s",
> + unknown_extensions.items[i].string);
> + *nongit_ok = -1;
> + ret = -1;
> + }
> +
> strbuf_release(&sb);
> return ret;
> }
> diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
> index 0d9388a..8dd6fd7 100755
> --- a/t/t1302-repo-version.sh
> +++ b/t/t1302-repo-version.sh
> @@ -67,4 +67,42 @@ test_expect_success 'gitdir required mode' '
> )
> '
>
> +check_allow () {
> + git rev-parse --git-dir >actual &&
> + echo .git >expect &&
> + test_cmp expect actual
> +}
> +
> +check_abort () {
> + test_must_fail git rev-parse --git-dir
> +}
> +
> +# avoid git-config, since it cannot be trusted to run
> +# in a repository with a broken version
> +mkconfig () {
> + echo '[core]' &&
> + echo "repositoryformatversion = $1" &&
> + shift &&
> +
> + if test $# -gt 0; then
> + echo '[extensions]' &&
> + for i in "$@"; do
> + echo "$i"
> + done
> + fi
> +}
> +
> +while read outcome version extensions; do
> + test_expect_success "$outcome version=$version $extensions" "
> + mkconfig $version $extensions >.git/config &&
> + check_${outcome}
> + "
> +done <<\EOF
> +allow 0
> +allow 1
> +allow 1 noop
> +abort 1 no-such-extension
> +allow 0 no-such-extension
> +EOF
> +
> test_done
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/2] prepare_packed_git(): refactor garbage reporting in pack directory
@ 2015-11-04 20:15 4% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2015-11-04 20:15 UTC (permalink / raw)
To: Doug Kelly; +Cc: Junio C Hamano, Git List, Eric Sunshine
On Wed, Nov 04, 2015 at 02:08:21PM -0600, Doug Kelly wrote:
> Currently there's no mtime-guarding logic (I dug up that conversation
> earlier, though, but after I'd done the respin on this series)... OK,
> in that case, I'll create a separate patch that tests/cleans up
> .bitmap, but doesn't touch .keep. This might be a small series since
> I think the logic for finding pack garbage doesn't know anything about
> .bitmap per-se, so it's looking like I'll extend that relevant code,
> before adding the handling in gc and appropriate tests.
I'd hoped you could reuse the list of extensions found in
builtin/repack.c (e.g., see remove_redundant_pack). But I guess that is
not connected with the garbage-reporting code. And anyway, the simple
list probably does not carry sufficient information (it does not know
that ".keep" is potentially more precious than ".idx", for example).
-Peff
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] resolve_gitlink_ref: ignore non-repository paths
@ 2016-01-22 22:31 4% ` Jeff King
2016-01-22 22:36 4% ` Stefan Beller
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2016-01-22 22:31 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Andreas Krey, Git Mailing List
On Fri, Jan 22, 2016 at 05:29:30PM -0500, Jeff King wrote:
> diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh
> index 88be904..c525656 100755
> --- a/t/t3000-ls-files-others.sh
> +++ b/t/t3000-ls-files-others.sh
> @@ -65,6 +65,13 @@ test_expect_success '--no-empty-directory hides empty directory' '
> test_cmp expected3 output
> '
>
> +test_expect_success 'ls-files --others handles non-submodule .git' '
> + mkdir not-a-submodule &&
> + echo foo >not-a-submodule/.git &&
> + git ls-files -o >output &&
> + test_cmp expected1 output
> +'
BTW, I scratched my head about why I was able to use "expected1" here
without having to add "not-a-submodule" to it. But the answer is that
the directory itself does not get mentioned (it is not a file!), and we
seem to always exclude ".git" paths entirely.
I'm not sure if that's the best thing in every case (what if you have
precious content in a ".git" file?), but this does behave exactly as a
valid ".git" would with an empty HEAD ref. So I think it's a reasonable
behavior in practice.
-Peff
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] resolve_gitlink_ref: ignore non-repository paths
2016-01-22 22:31 4% ` Jeff King
@ 2016-01-22 22:36 4% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2016-01-22 22:36 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, Andreas Krey, Git Mailing List
Impressive performance improvements. :)
On Fri, Jan 22, 2016 at 2:31 PM, Jeff King <peff@peff.net> wrote:
> BTW, what if you have
> precious content in a ".git" file?
I'd kindly ask to use a different version control in that case.
Q: What can you use Git for?
A: Everything including version control, backup, deploying software,
except when there is a file named .git with precious content.
;)
^ permalink raw reply [relevance 4%]
* Re: 'untracked working tree files would be overwritten by merge' on ignored files?
@ 2016-06-14 17:06 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2016-06-14 17:06 UTC (permalink / raw)
To: Andreas Krey; +Cc: git
Andreas Krey <a.krey@gmx.de> writes:
> when I have an ignored file in my workspace, is git
> then also assumed not to remove it in the course
> of a merge?
IIRC, untracked files are kept during merge and across checking out
another branch. Files that are deliberately marked as ignored by
listing them to .gitignore mechanism are considered expendable, and
they will be removed as necessary.
This is because we do not have the fourth-class, "we do not want to
add them to the history as tracked contents, but we do not want to
lose them", aka "precious"; we only have three, i.e. "paths in the
index", "path that are untracked" and "path that are ignored".
^ permalink raw reply [relevance 4%]
* Re: [PATCH] convert: mark a file-local symbol static
@ 2016-10-17 20:48 4% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2016-10-17 20:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramsay Jones, Jeff King, Johannes Schindelin, Lars Schneider,
GIT Mailing-list
On Mon, Oct 17, 2016 at 1:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
>
>> Heh, I actually have the following in my config.mak already:
>>
>> extra-clean: clean
>> find . -iname '*.o' -exec rm {} \;
>>
>> But for some reason I _always_ type 'make clean' and then, to top
>> it off, I _always_ type the 'find' command by hand (I have no idea
>> why) :-D
>
> "git clean -x" anybody?
I only want to cleanup compiled stuff and such, not the precious
unversioned text files I have laying around here. So I guess
git clean -x -e:(attr:!binary)
would suffice, though. ;)
^ permalink raw reply [relevance 4%]
* Re: Git issue - ignoring changes to tracked file with assume-unchanged
@ 2016-11-07 22:34 4% ` Jakub Narębski
0 siblings, 0 replies; 200+ results
From: Jakub Narębski @ 2016-11-07 22:34 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Halde, Faiz, git@vger.kernel.org
W dniu 01.11.2016 o 19:11, Junio C Hamano pisze:
> Jeff King <peff@peff.net> writes:
>> On Tue, Nov 01, 2016 at 10:28:57AM +0000, Halde, Faiz wrote:
>>
>>> I frequently use the following command to ignore changes done in a file
>>>
>>> git update-index --assume-unchanged somefile
>>>
>>> Now when I do a pull from my remote branch and say the file 'somefile'
>>> was changed locally and in remote, git will abort the merge saying I
>>> need to commit my changes of 'somefile'.
>>>
>>> But isn't the whole point of the above command to ignore the changes
>>> within the file?
>>
>> No. The purpose of --assume-unchanged is to promise git that you will
>> not change the file, so that it may skip checking the file contents in
>> some cases as an optimization.
>
> That's correct.
>
> The next anticipated question is "then how would I tell Git to
> ignore changes done to a file locally by me?", whose short answer is
> "You don't", of course.
Well, you can always use --skip-worktree. It is a better fit than using
--assume-unchanged, because at least you wouldn't loose your precious
local changes (which happened to me).
OTOH it doesn't solve your issue of --skip-worktree / --assume-unchanged
blocking operation (pull in your case, stash is what I noticed problem
with when using --skip-worktree).
But --skip-worktree is still workaround...
--
Jakub Narębski
^ permalink raw reply [relevance 4%]
* Re: Bug with .gitignore and branch switching
@ 2017-03-17 22:36 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-03-17 22:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Nevada Sanchez, git
Jonathan Nieder <jrnieder@gmail.com> writes:
> The most recent example I can find is 2010:
> http://public-inbox.org/git/4C6A1C5B.4030304@workspacewhiz.com/.
>
> It also came up in 2007:
> http://public-inbox.org/git/C0E9F681E68D48EB8989022D11FEE3D1@ntdev.corp.microsoft.com/
> Earlier in that year it even made the "What's not in 1.5.2" list.
> http://public-inbox.org/git/11793556383977-git-send-email-junkio@cox.net/
>
> Perhaps those references could be a useful starting point for an
> interested person's thinking.
Thanks for links. It seems that my thinking back in 1.5.3 timeperiod
was to introduce "precious" attribute.
I noticed that among the four-message "What's not in 1.5.2" series,
3/4 has a large discussion that may be relevant to Brandon's
"submodule is-active" thing.
^ permalink raw reply [relevance 4%]
* Re: Git allow to unconditionaly remove files on other developer host
@ 2017-04-15 12:27 4% ` Johannes Sixt
0 siblings, 0 replies; 200+ results
From: Johannes Sixt @ 2017-04-15 12:27 UTC (permalink / raw)
To: KES, git
Am 15.04.2017 um 13:36 schrieb KES:
> That curious, but git allow to unconditionally delete files on other developer host when he do `git pull`
>
> How to reproduce:
>
> 1. File should be ignored:
> echo "somefile" >> .gitignore
>
> 2. Add this ignored file into repository
> git add -f somefile
>
> 3. Push changes to origin
> git push
>
> 4. When other developer has also 'somefile' on his host and when he does
> git pull
>
> Content of hist local `somefile` file will be replaced by content pushed by first developer
This happens *only* if the other developers also have somefile mentioned
in their .gitignore.
>
> EXPECTED: git should warn about that content will be replaced and do not pull/checkout until we force pull/checkout
If somefile is *not* mentioned in their .gitignore, the file is not
removed and there is a warning.
Know that Git regards everything mentioned in .gitignore as dispensible;
IOW, by mentioning a file in .gitignore you actually give permission to
remove the file if necessary. Git does not have a feature to say "ignore
this file, but it is precious".
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension
@ 2017-07-28 13:20 4% ` Ben Peart
0 siblings, 0 replies; 200+ results
From: Ben Peart @ 2017-07-28 13:20 UTC (permalink / raw)
To: Junio C Hamano, Jonathan Tan; +Cc: git, christian.couder
On 7/27/2017 2:55 PM, Junio C Hamano wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> Currently, Git does not support repos with very large numbers of objects
>> or repos that wish to minimize manipulation of certain blobs (for
>> example, because they are very large) very well, even if the user
>> operates mostly on part of the repo, because Git is designed on the
>> assumption that every referenced object is available somewhere in the
>> repo storage.
>>
I very much like the direction this is taking. Handling missing objects
gracefully is an important part of the overall partial clone support.
>> Introduce a new repository extension option "extensions.lazyobject", of
>> data type string. If this is set in a repository, Git will tolerate
>> objects being missing in that repository. When Git needs those objects,
>> it will invoke the command in that option.
>
I'm very glad you are doing this. Having never used precious objects I
was unaware of the extensions concept but it looks like a great way to
deal with this repo specific option.
> My reading hiccupped after the first sentence, as the problem
> description made it sound like this was a boolean ("are we using
> lazy object feature?"), after reading "data type string". And then
> "the command in that option" made me hiccup one more time, as it did
> not "click" that "in that option" was trying to say that the string
> is used as the command name (or is it a whole command line? The
> leading part of the command line to which some arguments are
> appended before it gets invoked as a command? or what?).
>
> Logically, I think it is more like
>
> - extensions.lazyobject can be set to tell Git to consider missing
> objects in certain cases are not errors;
>
> - the value of extensions.lazyobject variable must be a string,
> which is used to name the command to lazily make the object
> "appear" in the repository on demand.
>
>> Teach fsck about the new state of affairs. In this commit, teach fsck
>> that missing objects referenced from the reflog are not an error case;
>> in future commits, fsck will be taught about other cases.
>
> In any case, sounds like a small and good first step.
>
I agree completely with the feedback on the description. That is quite
the run on sentence. :)
>> +
>> +`lazyObject`
>> +~~~~~~~~~~~~~~~~~
>> +
>> +When the config key `extensions.lazyObject` is set to a string, Git
>> +tolerates objects being missing in the repository. This string contains
>> +the command to be run whenever a missing object is needed.
>
> This has the same issue but to a lessor degree as there is "string
> contains". What the command will do (e.g. "makes the object
> magically appear in the object store" or "emits the contents of the
> object to its standard output, so that Git can hash it to make it
> appear in the object store"), and how it is used (e.g. "this is a
> single command name and nothing else", "this is a leading part of
> command line and arguments are appended at the end, before the whole
> thing is passed to the shell to be executed", etc.) will need to be
> clarified in the final version of the series (not necessarily at
> this step---the series can elaborate in the later patches).
>
>> diff --git a/builtin/fsck.c b/builtin/fsck.c
>> index fb0947009..1cfb8d98c 100644
>> --- a/builtin/fsck.c
>> +++ b/builtin/fsck.c
>> @@ -402,7 +402,7 @@ static void fsck_handle_reflog_oid(const char *refname, struct object_id *oid,
>> xstrfmt("%s@{%"PRItime"}", refname, timestamp));
>> obj->flags |= USED;
>> mark_object_reachable(obj);
>> - } else {
>> + } else if (!repository_format_lazy_object) {
>> error("%s: invalid reflog entry %s", refname, oid_to_hex(oid));
>> errors_found |= ERROR_REACHABLE;
>> }
>> diff --git a/cache.h b/cache.h
>> index 6c8242340..9e6bc0a21 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -853,10 +853,12 @@ extern int grafts_replace_parents;
>> #define GIT_REPO_VERSION 0
>> #define GIT_REPO_VERSION_READ 1
>> extern int repository_format_precious_objects;
>> +extern char *repository_format_lazy_object;
>
> This is not a new problem, but I think these two should be
> called repository_extension_$NAME not repository_format_$NAME.
>
>> diff --git a/t/t0410-lazy-object.sh b/t/t0410-lazy-object.sh
>> new file mode 100755
>> index 000000000..36442531f
>> --- /dev/null
>> +++ b/t/t0410-lazy-object.sh
>> @@ -0,0 +1,32 @@
>> +#!/bin/sh
>> +
>> +test_description='lazy object'
>> +
>> +. ./test-lib.sh
>> +
>> +delete_object () {
>> + rm $1/.git/objects/$(echo $2 | cut -c1-2)/$(echo $2 | cut -c3-40)
>> +}
>> +
>> +test_expect_success 'fsck fails on lazy object in reflog' '
>> + test_create_repo repo &&
>> + test_commit -C repo 1 &&
>> +
>> + A=$(git -C repo commit-tree -m a HEAD^{tree}) &&
>> + B=$(git -C repo commit-tree -m b HEAD^{tree}) &&
>> +
>> + # Reference $A only from reflog, and delete it
>> + git -C repo branch mybranch "$A" &&
>> + git -C repo branch -f mybranch "$B" &&
>> + delete_object repo "$A" &&
>> +
>> + test_must_fail git -C repo fsck
>> +'
>> +test_expect_success '...but succeeds if lazyobject is set' '
>> + git -C repo config core.repositoryformatversion 1 &&
>> + git -C repo config extensions.lazyobject "arbitrary string" &&
>> + git -C repo fsck
>> +'
>> +
>> +test_done
^ permalink raw reply [relevance 4%]
* Re: [RFC] Indicate that Git waits for user input via editor
@ 2017-11-15 18:37 4% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2017-11-15 18:37 UTC (permalink / raw)
To: Lars Schneider; +Cc: git
On Wed, Nov 15, 2017 at 10:07 AM, Lars Schneider
<larsxschneider@gmail.com> wrote:
>> Can this be put in a wrapper that opens the text editor?
>> The wrapper would print these lines and then open the text editor;
>> depending on the operating system, there might even be a command to
>> focus on that editor window.
>
> Yeah, that would be a workaround. However, in order to take these steps (write the
> wrapper, enable the focus command) the users needs to understand the problem.
> That's quite a leap especially for new Git users. They just get the feeling "Git
> is broken because it hangs".
>
> Can you imagine any downside for an "Opening editor for user input..." message?
"Wasting precious screen real estate for power users" (tm)
So maybe if one can turn it off, this would be ok? Or even for known inline
editors?
>> Regarding Git, maybe improve the documentation for how to set the editor
>> variable?
>
> The sad truth is that 98% of the users do not read the documentation
> (made up number but close to my observed reality).
Yeah that is an excellent point, but you forgot the people who
look at stackoverflow which of course links back to the docs in
the first excellent reply.
In a way this suggestion of bettering the docs was a cheap way out, sorry.
^ permalink raw reply [relevance 4%]
* Re: [PATCH] range-diff: allow to diff files regardless submodule
@ 2018-10-12 9:24 4% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2018-10-12 9:24 UTC (permalink / raw)
To: Lucas De Marchi
Cc: sandals, Lucas De Marchi, git, t.gummerer, sunshine, gitster
On Thu, 11 Oct 2018, Lucas De Marchi wrote:
> On Wed, Oct 10, 2018 at 5:02 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> > > Do like it's done in grep so mode doesn't end up as
> > > 0160000, which means range-diff doesn't work if one has
> > > "submodule.diff = log" in the configuration. Without this
> > > while using range-diff I only get a
> > >
> > > Submodule a 0000000...0000000 (new submodule)
> > >
> > > instead of the diff between the revisions.
> > >
> > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > ---
> > > range-diff.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/range-diff.c b/range-diff.c
> > > index 60edb2f518..bd8083f2d1 100644
> > > --- a/range-diff.c
> > > +++ b/range-diff.c
> > > @@ -354,7 +354,7 @@ static struct diff_filespec *get_filespec(const char *name, const char *p)
> > > {
> > > struct diff_filespec *spec = alloc_filespec(name);
> > >
> > > - fill_filespec(spec, &null_oid, 0, 0644);
> > > + fill_filespec(spec, &null_oid, 0, 0100644);
> >
> > If we have a system that has different mode values from the common Unix
> > ones, is this still correct or does it need to change?
>
> From what I can see this would still be correct, or at least git-grep
> implementation would be broken.
As you can see from the Windows port: we are stuck with the simplistic
POSIX permissions in Git, and platforms that have a different permission
system have to emulate it.
We only use preciously few bit masks, anyway. For example, we do not
really use the lower 12 bits for anything but "executable or not?"
So Lucas' patch is correct, AFAICT.
Ciao,
Dscho
>
> Lucas De Marchi
> > --
> > brian m. carlson: Houston, Texas, US
> > OpenPGP: https://keybase.io/bk2204
>
>
>
> --
> Lucas De Marchi
>
^ permalink raw reply [relevance 4%]
* Re: Ignored files being silently overwritten when switching branches
@ 2018-10-16 15:05 4% ` Duy Nguyen
2018-10-18 1:55 4% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Duy Nguyen @ 2018-10-16 15:05 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jeff King, per.lundberg, Git Mailing List, Junio C Hamano, git,
Clemens Buchacher, Holger Hellmuth (IKS), Kevin Ballard
On Tue, Oct 16, 2018 at 11:12 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Tue, Oct 16 2018, Jeff King wrote:
>
> > On Mon, Oct 15, 2018 at 01:01:50PM +0000, Per Lundberg wrote:
> >
> >> Sorry if this question has been asked before; I skimmed through the list
> >> archives and the FAQ but couldn't immediately find it - please point me
> >> in the right direction if it has indeed been discussed before.
> >
> > It is a frequently asked question, but it doesn't seem to be in any FAQ
> > that I could find. The behavior you're seeing is intended. See this
> > message (and the rest of the thread) for discussion:
> >
> > https://public-inbox.org/git/7viq39avay.fsf@alter.siamese.dyndns.org/
> >
> >> So my question is: is this by design or should this be considered a bug
> >> in git? Of course, it depends largely on what .gitignore is being used
> >> for - if we are talking about files which can easily be regenerated
> >> (build artifacts, node_modules folders etc.) I can totally understand
> >> the current behavior, but when dealing with more sensitive & important
> >> content it's a bit inconvenient.
> >
> > Basically: yes. It would be nice to have that "do not track this, but do
> > not trash it either" state for a file, but Git does not currently
> > support that.
>
> There's some patches in that thread that could be picked up by someone
> interested. I think the approach mentioned by Matthieu Moy here makes
> the most sense:
> https://public-inbox.org/git/vpqd3t9656k.fsf@bauges.imag.fr/
>
> I don't think the rationale mentioned by Junio in
> https://public-inbox.org/git/7v4oepaup7.fsf@alter.siamese.dyndns.org/ is
> very convincing.
Just fyi I also have some wip changes that add the forth "precious"
class in addition to tracked, untracked and ignored [1]. If someone
has time it could be another option to pick up.
[1] https://gitlab.com/pclouds/git/commit/0e7f7afa1879b055369ebd3f1224311c43c8a32b
--
Duy
^ permalink raw reply [relevance 4%]
* Re: Ignored files being silently overwritten when switching branches
2018-10-16 15:05 4% ` Duy Nguyen
@ 2018-10-18 1:55 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-10-18 1:55 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Jeff King, per.lundberg,
Git Mailing List, git, Clemens Buchacher, Holger Hellmuth (IKS),
Kevin Ballard
Duy Nguyen <pclouds@gmail.com> writes:
> Just fyi I also have some wip changes that add the forth "precious"
> class in addition to tracked, untracked and ignored [1]. If someone
> has time it could be another option to pick up.
It is much more sensible than gaining the ability to express
precious by trading away the ability to express expendable, I would
think.
^ permalink raw reply [relevance 4%]
* Re: git overwriting local ignored files?
@ 2018-11-24 4:22 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-11-24 4:22 UTC (permalink / raw)
To: David Mandelberg; +Cc: git
David Mandelberg <david@mandelberg.org> writes:
> It seems that git is overwriting my local files on merge if they're in
> .gitignore. See command transcript below. I searched `git help config`
> and Google, but I couldn't find any way to prevent it. Am I missing
> something? (The reason I care about ignored files is that I'm using
> git with a working directory of $HOME to manage my dotfiles, and most
> files in my $HOME are not tracked by git but are still important.)
The .gitignore file is to list "ignored and expendable" class of
files; there is no "ignored but precious class" in Git.
^ permalink raw reply [relevance 4%]
* Re: [RFC] git clean --local
@ 2018-12-02 0:04 4% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Junio C Hamano @ 2018-12-02 0:04 UTC (permalink / raw)
To: Cameron Boehmer; +Cc: git
Cameron Boehmer <cameron.boehmer@gmail.com> writes:
> 1) add a new flag
> -l, --local
> Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.
This does not belong to the "clean" command (who says the need to
ignore the global configuration is limited to "clean" and why?), so
"git clean --local" is simply not acceptable.
But it might be useful as an option that affects any "git" command,
e.g. "git --local-config-only clean". I dunno.
> 2) change the behavior of -x/-X
This won't happen without a long deprecation period.
If you haven't seen and read them, check the recent list archive for
the past few weeks, with keywords "trashable", "precious", etc.
^ permalink raw reply [relevance 4%]
* RE: [RFC] git clean --local
@ 2018-12-02 17:37 4% ` Randall S. Becker
2018-12-02 19:37 4% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Randall S. Becker @ 2018-12-02 17:37 UTC (permalink / raw)
To: 'Ævar Arnfjörð Bjarmason',
'Cameron Boehmer'
Cc: git
On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
>
> > 1) add a new flag
> > -l, --local
> > Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is useful in conjunction with
> > -x/-X to preserve user files while removing build artifacts.
>
> Or perhaps a general flag to ignore configuration would be useful for such
> cases, see https://public-
> inbox.org/git/87zhtqvm66.fsf@evledraar.gmail.com/
Would something like git clean --exclude=file-pattern work as a compromise notion? Files matching the pattern would not be cleaned regardless of .gitignore or their potential preciousness status long-term. Multiple repetitions of the --exclude option might be supportable. I could see that being somewhat useful in scripting.
Cheers,
Randall
^ permalink raw reply [relevance 4%]
* Re: [RFC] git clean --local
2018-12-02 17:37 4% ` Randall S. Becker
@ 2018-12-02 19:37 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-12-02 19:37 UTC (permalink / raw)
To: Randall S. Becker
Cc: 'Ævar Arnfjörð Bjarmason',
'Cameron Boehmer', git
"Randall S. Becker" <rsbecker@nexbridge.com> writes:
> Would something like git clean --exclude=file-pattern work as a
> compromise notion? Files matching the pattern would not be cleaned
> regardless of .gitignore or their potential preciousness status
> long-term. Multiple repetitions of the --exclude option might be
> supportable. I could see that being somewhat useful in scripting.
I think "git clean" already takes "-e", but I am not sure if it is
meant to do what you wrote above.
If "git clean" takes a pathspec, perhaps you can give a negative
pathspec to exclude whatever you do not want to get cleaned,
something like
git clean '*.o' ':!precious.o'
to say "presious.o is ignored (hence normally expendable), but I do
not want to clean it with this invocation of 'git clean'"?
^ permalink raw reply [relevance 4%]
* Re: There should be a `.gitbless; file, protecting files from git clean
@ 2019-01-28 5:05 4% ` Duy Nguyen
2019-01-28 5:24 4% ` Sebastian Gniazdowski
0 siblings, 1 reply; 200+ results
From: Duy Nguyen @ 2019-01-28 5:05 UTC (permalink / raw)
To: Sebastian Gniazdowski; +Cc: Git Mailing List
On Mon, Jan 28, 2019 at 9:54 AM Sebastian Gniazdowski
<psprint@zdharma.org> wrote:
>
> Hello,
> Keepiing repo clean with `git clean -dxf' is a very pleasant experience. However, ability to use it ends when one gets untracked but *wanted* files in the repo, like an untracked TODO.
>
> Could a .gitbless file be a solution? I would list in it, e.g.:
>
> TODO
>
> and this way be able to use `git -dxf' again. What do you think?
There's a patch that adds "precious" git attribute [1]. I was going to
resend once the backup-log [2] got reviewed but I might just send it
separately to handle the "git clean" case alone.
[1] https://public-inbox.org/git/20181111095254.30473-1-pclouds@gmail.com/
[2] https://public-inbox.org/git/20181209104419.12639-1-pclouds@gmail.com/
>
> --
> Sebastian Gniazdowski
> News: https://twitter.com/ZdharmaI
> IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
> Blog: http://zdharma.org
>
--
Duy
^ permalink raw reply [relevance 4%]
* Re: There should be a `.gitbless; file, protecting files from git clean
2019-01-28 5:05 4% ` Duy Nguyen
@ 2019-01-28 5:24 4% ` Sebastian Gniazdowski
0 siblings, 0 replies; 200+ results
From: Sebastian Gniazdowski @ 2019-01-28 5:24 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
On 28 stycznia 2019 at 06:05:31, Duy Nguyen (pclouds@gmail.com) wrote:
> On Mon, Jan 28, 2019 at 9:54 AM Sebastian Gniazdowski
> wrote:
> >
> > Hello,
> > Could a .gitbless file be a solution? I would list in it, e.g.:
> >
> > TODO
> >
> > and this way be able to use `git -dxf' again. What do you think?
>
> There's a patch that adds "precious" git attribute [1]. I was going to
> resend once the backup-log [2] got reviewed but I might just send it
> separately to handle the "git clean" case alone.
That would be nice solution. In the email, you ask for a name other than "precious". So maybe "blessed"?
--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org
^ permalink raw reply [relevance 4%]
* Re: What's cooking in git.git (Apr 2019, #01; Thu, 4)
@ 2019-04-04 11:08 4% ` Duy Nguyen
0 siblings, 0 replies; 200+ results
From: Duy Nguyen @ 2019-04-04 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
On Thu, Apr 4, 2019 at 5:29 PM Junio C Hamano <gitster@pobox.com> wrote:
> * nd/precious (2019-04-01) 1 commit
> - Introduce "precious" file concept
>
> "git clean" learned to pay attention to the 'precious' attributes
> and keep untracked paths with the attribute instead of removing.
>
> Will merge to 'next'.
There was no conclusion from the last thread if I remember correctly
and I kind of gave up on it. If you want to include anyway, should we
go for a more specific attribute (e.g. "clean") and leave "precious"
for later whenever it's better defined?
--
Duy
^ permalink raw reply [relevance 4%]
* Re: [BUG] rebase --interactive silently overwrites ignored files
@ 2019-04-12 16:30 4% ` Phillip Wood
2019-04-14 1:59 4% ` wh
0 siblings, 1 reply; 200+ results
From: Phillip Wood @ 2019-04-12 16:30 UTC (permalink / raw)
To: wh, git
Hi
On 12/04/2019 00:56, wh wrote:
> I'm using git 2.20.1 from Debian. Git is usually careful not to
> overwrite untracked files, including ignored files.
Git normally overwrites ignored files, so I think in your example rebase
-i is working as expected, I'm surprised that the am based rebase does
not overwrite the ignored file. There has been some discussion about
introducing 'precious' files that are ignored but protected in the same
way as untracked files [1].
Best Wishes
Phillip
[1] https://public-inbox.org/git/20190409102649.22115-1-pclouds@gmail.com/
But interactive
> rebase doesn't detect this (non-interactive rebase works fine).
>
> Reproduction:
> -----
>
> #!/bin/sh
> mkdir upstream
> cd upstream
> git init
> echo 1 >feature-1
> git add feature-1
> git commit -m "feature 1"
>
> cd ..
> git clone upstream local
> cd local
> # write some tools for our own convenience
> echo ours >tools
> echo /tools >>.git/info/exclude
> # start working on a feature
> git checkout -b f2
> echo wip >feature-2
> git add feature-2
> git commit -m "wip"
>
> cd ../upstream
> # official tools are available
> echo theirs >tools
> git add tools
> git commit -m "tools"
>
> cd ../local
> git fetch ../upstream master
>
> # this would be okay
> #git rebase FETCH_HEAD
>
> # problem: overwrites tools silently
> GIT_EDITOR=true git rebase -i FETCH_HEAD
>
> cat tools
>
> -----
>
> Expected: `git rebase -i` fails because it would have to overwrite the
> untracked "tools" file. Contents of tools file remains `ours`.
>
> Actual: Contents of tools file becomes `theirs`.
>
^ permalink raw reply [relevance 4%]
* Re: [BUG] rebase --interactive silently overwrites ignored files
2019-04-12 16:30 4% ` Phillip Wood
@ 2019-04-14 1:59 4% ` wh
0 siblings, 1 reply; 200+ results
From: wh @ 2019-04-14 1:59 UTC (permalink / raw)
To: phillip.wood; +Cc: git
Thanks for the info about the upcoming "precious" attribute. Looks useful.
I didn't get the impression that Git normally overwrites ignored
files. I ran some more experiments:
git rebase FETCH_HEAD # bails
git rebase -i FETCH_HEAD # overwrites
git merge FETCH_HEAD # bails
git reset --keep FETCH_HEAD # bails
git reset --merge FETCH_HEAD # bails
git checkout FETCH_HEAD # overwrites
# without feature 2 locally:
git merge FETCH_HEAD # overwrites, fast-forwards
git merge --no-ff FETCH_HEAD # bails
On Fri, Apr 12, 2019 at 9:30 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> Hi
>
> On 12/04/2019 00:56, wh wrote:
> > I'm using git 2.20.1 from Debian. Git is usually careful not to
> > overwrite untracked files, including ignored files.
>
> Git normally overwrites ignored files, so I think in your example rebase
> -i is working as expected, I'm surprised that the am based rebase does
> not overwrite the ignored file. There has been some discussion about
> introducing 'precious' files that are ignored but protected in the same
> way as untracked files [1].
>
> Best Wishes
>
> Phillip
>
> [1] https://public-inbox.org/git/20190409102649.22115-1-pclouds@gmail.com/
>
> But interactive
> > rebase doesn't detect this (non-interactive rebase works fine).
> >
> > Reproduction:
> > -----
> >
> > #!/bin/sh
> > mkdir upstream
> > cd upstream
> > git init
> > echo 1 >feature-1
> > git add feature-1
> > git commit -m "feature 1"
> >
> > cd ..
> > git clone upstream local
> > cd local
> > # write some tools for our own convenience
> > echo ours >tools
> > echo /tools >>.git/info/exclude
> > # start working on a feature
> > git checkout -b f2
> > echo wip >feature-2
> > git add feature-2
> > git commit -m "wip"
> >
> > cd ../upstream
> > # official tools are available
> > echo theirs >tools
> > git add tools
> > git commit -m "tools"
> >
> > cd ../local
> > git fetch ../upstream master
> >
> > # this would be okay
> > #git rebase FETCH_HEAD
> >
> > # problem: overwrites tools silently
> > GIT_EDITOR=true git rebase -i FETCH_HEAD
> >
> > cat tools
> >
> > -----
> >
> > Expected: `git rebase -i` fails because it would have to overwrite the
> > untracked "tools" file. Contents of tools file remains `ours`.
> >
> > Actual: Contents of tools file becomes `theirs`.
> >
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/3] git-gui: Add the ability to revert selected lines
@ 2019-08-20 21:19 4% ` Johannes Sixt
0 siblings, 0 replies; 200+ results
From: Johannes Sixt @ 2019-08-20 21:19 UTC (permalink / raw)
To: Pratyush Yadav; +Cc: git, Junio C Hamano
Am 20.08.19 um 21:29 schrieb Pratyush Yadav:
> On 20/08/19 09:21PM, Johannes Sixt wrote:
>> Please don't do this. This confirmation dialog is unacceptable in my
>> workflow. I use reversals of hunks and lines frequently, almost like a
>> secondary code editor. My safety net is the undo function of the IDE,
>> which works across reloads that are triggered by these external edits.
>> These confirmations get in the way.
>
> But not everyone uses an IDE. I use vim and it does not have any such
> undo feature that works across reloads. Not one I'm aware of anyway. It
> is absolutely necessary IMO to ask the user for confirmation before
> deleting their work, unless we have a built in safety net.
But you have a safety net built-in: Commit the work, then do the
reversals in amend-mode. Now you can recover old state to your heart's
content. That's recommended anyway if stuff is potentially precious.
> So how about adding a config option that allows you to disable the
> confirmation dialog? Sounds like a reasonable compromise to me.
That's always an option. Needless to say that I'd prefer it off by
default; I don't need three safety nets.
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: [Feature Request] Option to make .git not read-only in cloned repos
@ 2019-08-26 19:18 4% ` SZEDER Gábor
0 siblings, 0 replies; 200+ results
From: SZEDER Gábor @ 2019-08-26 19:18 UTC (permalink / raw)
To: Albert Vaca Cintora; +Cc: Junio C Hamano, Philip Oakley, Johannes Sixt, git
On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora wrote:
> > Why don't you wrap your clone in a script that calls chmod -R u+w .git after the clone? This seems like a pretty trivial approach regardless of your workflow. This works in Linux, Mac, Windows (under cygwin-bash) and anything else POSIX-ish.
> >
>
> Wrapping `git clone` should work as a workaround. Although if that
> doesn't break anything... then why were those files read-only in the
> first place? :)
Those read-only object and pack files contain all the version history,
and, therefore, are precious. Making them read-only can protect
from accidental deletion.
> The fact that, from a formal point of view, those files are immutable
> doesn't seem to justify them being read-only (or, at least, doesn't
> follow any convention): there are plenty of immutable files on any
> system (eg: all binaries and libs, application assets like images and
> icons, pid/lock files for daemons, etc.) that are not made read-only.
None of those files are actually immutable: the next update will
overwrite the binaries, libs, and assets, stopping the daemon will
remove the pidfile.
OTOH, Git's object and pack files are indeed immutable.
^ permalink raw reply [relevance 4%]
* Re: Promoting Ethnics-Ess-Nix, a friends-based search-engine
@ 2019-09-16 17:16 4% ` Klaus Sembritzki
0 siblings, 0 replies; 200+ results
From: Klaus Sembritzki @ 2019-09-16 17:16 UTC (permalink / raw)
To: git
Hello all,
We know that this is for a technical-savvy audience, but as we are all
people with a soul, here comes a combination of both, the logical and
the emotional first waves of the GCHQ-propaganda-war.
First waves of the GCHQ-propaganda-war:
- Logic: This is the first wave of a propaganda-war, false from
injust-people gets us extinct in the long run.
- Emotions: We are precious, no pretentiousness, abuse, scare and
disgust. Everything where it belongs.
Cheers,
The GCHQ
On Mon, Sep 16, 2019 at 4:09 PM Klaus Sembritzki <klausem@gmail.com> wrote:
>
> Dear all,
>
> We texted a README.md on a new project hosted on GitHub, promoting but
> not yet implementing a "friends-based search-engine", hosting the
> complete WWW in the future, thereby reshaping GIT and HG also. Now we
> figured we'd like to advertise the project to you directly.
>
> https://github.com/ksemb/Ethnics-Ess-Nix-friends-based-search-engine
>
> Please note that appropriateness is triple-solved to be necessity,
> constrained to knowledge and feasibility, making this a perfectly-fine
> email.
>
> This is the first wave of a propaganda-war, false from injust-people
> gets us extinct in the long run.
>
> Cheers,
> The GCHQ
^ permalink raw reply [relevance 4%]
* [PATCH 1/7] Makefile: mark 'check-builtins' as a .PHONY target
@ 2021-03-16 0:56 4% ` Denton Liu
0 siblings, 0 replies; 200+ results
From: Denton Liu @ 2021-03-16 0:56 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Junio C Hamano
Then convention in Git's Makefile is to mark targets which do not
actually generate any precious files (such as static checking targets).
.PHONY enables the target to still run, even if a file is erroneously
created with the same name as the target.
Mark 'check-builtins' as a .PHONY target.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index dfb0f1000f..6dbecdb606 100644
--- a/Makefile
+++ b/Makefile
@@ -3236,6 +3236,7 @@ check-docs::
### Make sure built-ins do not have dups and listed in git.c
#
+.PHONY: check-builtins
check-builtins::
./check-builtins.sh
--
2.31.0.rc2.261.g7f71774620
^ permalink raw reply related [relevance 4%]
* Re: No error when overwriting ignored files
@ 2021-04-07 20:47 4% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-04-07 20:47 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> When pulling from a repository that tracks a file listed in
> `.gitignore` that would overwrite a local file, this is not
> reported.
Git has the notion of "not to be tracked (i.e. added to the index or
committed) and expendable files", and they are called "ignored"
files. And ".gitignore" and .git/info/exclude mechanism is used to
mark these paths.
There is no notion of "not to be tracked but precious files" or
mechanism to mark paths as such. So the behaviour you observed is
fully expected and working as designed.
Thanks.
^ permalink raw reply [relevance 4%]
* Re: [feature suggestion] Add 'git stash export', 'git stash import' commands to allow to backup stash externally
@ 2021-05-06 6:07 4% ` Johannes Sixt
0 siblings, 1 reply; 200+ results
From: Johannes Sixt @ 2021-05-06 6:07 UTC (permalink / raw)
To: Yuri; +Cc: Git Mailing List
Am 05.05.21 um 21:51 schrieb Yuri:
> I work in a very large repository, but all of it except for my stashed
> items can be re-downloaded from the remote URL.
>
>
> Stash though is much smaller in size and is especially valuable. Its
> loss would be very expensive.
I would argue that you are doing something wrong if your stashes are
particularly valuable. If you regularly revert temporary, but precious
work, then you should commit the work and mark it with a branch tip or tag.
> Could you please consider adding 'git stash export', 'git stash import'
> commands so that in case of an accidental repository loss stash can be
> imported from the external backup?
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: [feature suggestion] Add 'git stash export', 'git stash import' commands to allow to backup stash externally
@ 2021-05-06 6:43 4% ` Johannes Sixt
0 siblings, 0 replies; 200+ results
From: Johannes Sixt @ 2021-05-06 6:43 UTC (permalink / raw)
To: Yuri; +Cc: Git Mailing List
Am 06.05.21 um 08:12 schrieb Yuri:
> On 5/5/21 11:07 PM, Johannes Sixt wrote:
>> I would argue that you are doing something wrong if your stashes are
>> particularly valuable. If you regularly revert temporary, but precious
>> work, then you should commit the work and mark it with a branch tip or
>> tag.
>>
>
> No, it is work in progress. I begin to work on some modification or
> update, discover some issue, and stash the update until this issue is
> resolved,
>
> It could take days, weeks, months to resolve them.
I know. But, as I said, when you turn away from your current work, which
is precious, then you should make a commit, in particular, when you can
forsee that you might not be able to come back soon.
A 'git stash' is really only intended as a short-term
make-the-worktree-temporarily-clean auxiliary storage. It is not
intended as a long-term storage. For long-term storage, use branches.
"Short term" is measured in seconds (rebase --autostash), minutes,
perhaps hours, but certainly not weeks or months.
At least, that's how I understand (and use) it.
-- Hannes
^ permalink raw reply [relevance 4%]
* Re: The git spring cleanup challenge
@ 2021-06-01 10:07 4% ` Felipe Contreras
0 siblings, 0 replies; 200+ results
From: Felipe Contreras @ 2021-06-01 10:07 UTC (permalink / raw)
To: Andy, Felipe Contreras, git
Andy wrote:
> My understanding is that even if it's not an advanced question about the
> details of development, but just a general question, it's still possible
> to discuss it on this mailing list.
Yes it is.
> At the moment my configuration file is quite short, but you mentioned
> that the configuration files of the masters are often very long, which
> reminds me that there is a lot of room for optimization.
Indeed. But efen if it's short, do you need more than 2 configurations?
(other than user.{name,email})? If so, maybe you could participate too,
and let us know which you couldn't live without.
> Getting out of your comfort zone is not even an easy task, and
> understanding the problem clearly does require preventing expert bias,
> which is not easy.
Exactly. And getting rid of our precious ~/.gitconfig (even if it's just
for a while) is a straightforward way to force us out.
Cheers.
--
Felipe Contreras
^ permalink raw reply [relevance 4%]
* Re: Request feature: –no-submodule
@ 2021-06-05 5:45 4% ` Ilias Apostolou
0 siblings, 0 replies; 200+ results
From: Ilias Apostolou @ 2021-06-05 5:45 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Taylor Blau, git@vger.kernel.org
If I understand correctly, we should learn to use git ls-files special
parameters like 'attr' and 'exclude'. I'm impressed by the fact that
these are not wide-spread known. We should learn to use these advanced
features instead of extra piping. Your emails are precious to my team
and will help us advance.
Please consider this request closed.
Ilias
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 0/7] Drop support for git rebase --preserve-merges
@ 2021-09-02 14:18 4% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2021-09-02 14:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin via GitGitGadget, git, Eric Wong,
Johannes Sixt
Hi Junio,
On Wed, 1 Sep 2021, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > In 427c3bd28ab (rebase: deprecate --preserve-merges, 2019-03-11) (which was
> > included in v2.22.0), we officially deprecated the --preserve-merges
> > backend. Over two years later, it is time to drop that backend, and here is
> > a patch series that does just that.
>
> A good goal. There is no remaining use case where (a fictitious and
> properly working version of) "--preserve-merges" option cannot be
> replaced by "--rebase-merges", is it? I somehow had a feeling that
> the other Johannes (sorry if it weren't you, j6t) had cases that the
> former worked better, but perhaps I am mis-remembering things.
I think that I managed to address whatever concerns there were about the
`--rebase-merges` backend in the meantime.
To be honest, I developed one (minor) concern in the meantime... Should we
maybe try to be nicer to our users and keep handling the
`--preserve-merges` option by explicitly erroring out with the suggestion
to use `--rebase-merges` instead? Not everybody reads release notes, after
all. In fact, it is my experience that preciously few users have the time
to even skim release notes...
Ciao,
Dscho
^ permalink raw reply [relevance 4%]
* Re: Aborting 'rebase main feat' removes unversioned files
@ 2021-09-05 7:43 4% ` Ævar Arnfjörð Bjarmason
2021-09-08 0:40 5% ` Elijah Newren
0 siblings, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2021-09-05 7:43 UTC (permalink / raw)
To: Elijah Newren; +Cc: Jeff King, Fedor Biryukov, Bagas Sanjaya, Git Mailing List
On Sat, Sep 04 2021, Elijah Newren wrote:
> On Sat, Sep 4, 2021 at 3:19 AM Jeff King <peff@peff.net> wrote:
>>
>> On Sat, Sep 04, 2021 at 11:51:19AM +0200, Fedor Biryukov wrote:
>>
>> > There is no way this could be the intended behavior, but the good news
>> > is that I cannot reproduce it...
>> > Looks like it occurs only in one git version (2.31.0.windows.1, IIRC).
>> > And it does not occur in the latest git version: git version 2.33.0.windows.2.
>>
>> I think it is a bug, and it seems to reproduce easily for me (with both
>> the current tip of master, and with v2.33.0). Here's the recipe you
>> showed, with a little debugging at the end:
>>
>> set -x
>> git init repo
>> cd repo
>> git commit -m base --allow-empty
>> git checkout -b feat
>> echo feat >readme.txt
>> git add readme.txt
>> git commit -m txt=feat
>> git checkout main
>> echo precious >readme.txt
>>
>> cat readme.txt
>> git checkout feat
>> cat readme.txt
>> git rebase main feat
>> cat readme.txt
>>
>> This produces:
>>
>> + cat readme.txt
>> precious
>> + git checkout feat
>> error: The following untracked working tree files would be overwritten by checkout:
>> readme.txt
>> Please move or remove them before you switch branches.
>> Aborting
>> + cat readme.txt
>> precious
>> + git rebase main feat
>> Current branch feat is up to date.
>> + cat readme.txt
>> feat
>>
>> So git-checkout was not willing to overwrite the untracked content, but
>> rebase was happy to obliterate it.
>>
>> It does the right thing in very old versions. Bisecting, it looks like
>> the problem arrived in 5541bd5b8f (rebase: default to using the builtin
>> rebase, 2018-08-08). So the bug is in the conversion from the legacy
>> shell script to C (which makes sense; the shell version was just calling
>> "git checkout", which we know does the right thing).
>>
>> -Peff
>
> Turns out this is quite a mess. It's also related to the "don't
> remove empty working directories" discussion we had earlier this
> week[1], because we assumed all relevant codepaths correctly avoided
> deleting untracked files and directories in the way. But they don't.
> And rebase isn't the only offender, because this is buried in
> unpack_trees. In fact, it traces back to (and before)
> fcc387db9b ("read-tree -m -u: do not overwrite or remove untracked
> working tree files.", 2006-05-17)
> which has additional commentary over at
> https://lore.kernel.org/git/7v8xp1jc9h.fsf_-_@assigned-by-dhcp.cox.net/.
> It appears that before this time, git happily nuked untracked files
> and considered them expendable, in basically all cases. However, this
> patch continued considering them as expendable whenever opts->reset
> was true. There wasn't much comment about it at the time for the
> reasoning of how opts->reset was handled, though trying to read
> between the lines perhaps Junio was trying to limit the backward
> compatibility concerns of introducing new errors to fewer code paths?
> Anyway, Junio did mention `read-tree --reset` explicitly, but this
> opts->reset usage also occurs in am, checkout, reset -- and anything
> that calls the reset_head() function including: rebase, stash,
> sequencer.c, and add-patch.c.
>
> So, then...should we preserve untracked (and non-ignored) files in all
> these cases? This rebase case seems clear, but others might be less
> clear. For example, should "git reset --hard" nuke untracked files
> (what if it's a directory of untracked files getting nuked just to
> place a single file in the location of the directory)? The
> documentation isn't explicit, but after reading it I would assume that
> untracked files should be preserved. Since we've had bugs in "git
> reset --hard" before, such as requiring two invocations in order to
> clear out unmerged entries (see [2] and [3]), that also suggests that
> this is just another bug in the same area. But the bug has been
> around so long that people might be expecting it; our testsuite has
> several cases that incidentally do. Granted, it's better to throw an
> error and require explicit extra steps than to nuke potentially
> important work, but some folks might be unhappy with a change here.
> Similarly with "git checkout -f".
>
> And stash.c, which operates in that edge case area has tests with
> files nuked from the cache without nuking it from the working tree
> (causing the working tree file to be considered untracked), and then
> attempts to have multiple tests operate on that kind of case. Those
> cases look a bit buggy to me for other reasons (I'm still digging),
> but those bugs are kind of hidden by the untracked file nuking bugs,
> so fixing the latter requires fixing the former. And stash.c is a
> mess of shelling out to subcommands. Ick.
>
> I have some partial patches, but don't know if I'll have anything to
> post until I figure out the stash mess...
I'd just like to applaud this effort, and also suggest that the most
useful result of any such findings would be for us to produce some new
test in t/ showing these various cases of nuking/clobbering and other
"non-precious" edge cases in this logic. See[1] and its linked [2] for
references to some of the past discussions around these cases.
1. https://lore.kernel.org/git/87a6q9kacx.fsf@evledraar.gmail.com/
2. https://lore.kernel.org/git/87ftsi68ke.fsf@evledraar.gmail.com/
> [1] https://lore.kernel.org/git/YS8eEtwQvF7TaLCb@coredump.intra.peff.net/
> [2] 25c200a700 ("t1015: demonstrate directory/file conflict recovery
> failures", 2018-07-31)
> [3] ad3762042a ("read-cache: fix directory/file conflict handling in
> read_index_unmerged()", 2018-07-31)
^ permalink raw reply [relevance 4%]
* Should help.autocorrect be on by default?
@ 2021-09-30 17:15 4% Brian Bartels
0 siblings, 0 replies; 200+ results
From: Brian Bartels @ 2021-09-30 17:15 UTC (permalink / raw)
To: git
This would save developers precious inner loop time. I looked at the
code and it already handles cases where the environment isn't
interactive. So this should be a pretty minor configuration change.
Let me know what you think,
Brian
^ permalink raw reply [relevance 4%]
* Re: [PATCH 7/8] core.fsync: new option to harden loose references
@ 2022-03-10 22:54 4% ` Neeraj Singh
0 siblings, 0 replies; 200+ results
From: Neeraj Singh @ 2022-03-10 22:54 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Git List, Randall S. Becker, Bagas Sanjaya, Elijah Newren,
Ævar Arnfjörð Bjarmason, brian m. carlson,
Neeraj K. Singh, Junio C Hamano
On Thu, Mar 10, 2022 at 1:53 AM Patrick Steinhardt <ps@pks.im> wrote:
> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
> index 973805e8a9..b67d3c340e 100644
> --- a/Documentation/config/core.txt
> +++ b/Documentation/config/core.txt
> @@ -564,8 +564,10 @@ core.fsync::
> * `pack-metadata` hardens packfile bitmaps and indexes.
> * `commit-graph` hardens the commit graph file.
> * `index` hardens the index when it is modified.
> +* `loose-ref` hardens references modified in the repo in loose-ref form.
> * `objects` is an aggregate option that is equivalent to
> `loose-object,pack`.
> +* `refs` is an aggregate option that is equivalent to `loose-ref`.
> * `derived-metadata` is an aggregate option that is equivalent to
> `pack-metadata,commit-graph`.
> * `default` is an aggregate option that is equivalent to
> diff --git a/cache.h b/cache.h
> index 63a95d1977..b56a56f539 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1005,11 +1005,14 @@ enum fsync_component {
> FSYNC_COMPONENT_PACK_METADATA = 1 << 2,
> FSYNC_COMPONENT_COMMIT_GRAPH = 1 << 3,
> FSYNC_COMPONENT_INDEX = 1 << 4,
> + FSYNC_COMPONENT_LOOSE_REF = 1 << 5,
> };
>
> #define FSYNC_COMPONENTS_OBJECTS (FSYNC_COMPONENT_LOOSE_OBJECT | \
> FSYNC_COMPONENT_PACK)
>
> +#define FSYNC_COMPONENTS_REFS (FSYNC_COMPONENT_LOOSE_REF)
> +
> #define FSYNC_COMPONENTS_DERIVED_METADATA (FSYNC_COMPONENT_PACK_METADATA | \
> FSYNC_COMPONENT_COMMIT_GRAPH)
>
> @@ -1026,7 +1029,8 @@ enum fsync_component {
> FSYNC_COMPONENT_PACK | \
> FSYNC_COMPONENT_PACK_METADATA | \
> FSYNC_COMPONENT_COMMIT_GRAPH | \
> - FSYNC_COMPONENT_INDEX)
> + FSYNC_COMPONENT_INDEX | \
> + FSYNC_COMPONENT_LOOSE_REF)
>
> /*
> * A bitmask indicating which components of the repo should be fsynced.
> diff --git a/config.c b/config.c
> index f03f27c3de..b5d3e6e404 100644
> --- a/config.c
> +++ b/config.c
> @@ -1332,7 +1332,9 @@ static const struct fsync_component_entry {
> { "pack-metadata", FSYNC_COMPONENT_PACK_METADATA },
> { "commit-graph", FSYNC_COMPONENT_COMMIT_GRAPH },
> { "index", FSYNC_COMPONENT_INDEX },
> + { "loose-ref", FSYNC_COMPONENT_LOOSE_REF },
> { "objects", FSYNC_COMPONENTS_OBJECTS },
> + { "refs", FSYNC_COMPONENTS_REFS },
> { "derived-metadata", FSYNC_COMPONENTS_DERIVED_METADATA },
> { "default", FSYNC_COMPONENTS_DEFAULT },
> { "committed", FSYNC_COMPONENTS_COMMITTED },
In terms of the 'preciousness-levels', refs should be included in
FSYNC_COMPONENTS_COMMITTED,
from which it will also be included in _ADDED.
^ permalink raw reply [relevance 4%]
* Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory
@ 2024-01-24 14:22 4% ` Raúl Núñez de Arenas Coronado
0 siblings, 0 replies; 200+ results
From: Raúl Núñez de Arenas Coronado @ 2024-01-24 14:22 UTC (permalink / raw)
To: Jeff King; +Cc: git
Hi Jeff!
El mié, 24 ene 2024 a las 2:09, Jeff King (<peff@peff.net>) escribió:
> (I think this also gives an interesting use case arguing for continuing
> to support those more-specific exclusion options for ls-files).
>
> If you are mostly just using core.excludesFile (and not
> .git/info/exclude), then I suspect:
>
> git -c core.excludesFile /dev/null ls-files -o --exclude-standard
>
> would work for you, too (but it sounds like you might also be using
> .git/info/exclude).
In my case, since I'm also using .git/info/exclude in some repos, this
won't work as-is, but you gave me an idea, and I think I can get what
I need until the "precious" mechanism is implemented. It requires a
bit of hacking in the backup script but is not a big deal and it will
work for all my current repos.
Thanks for the help!
--
Raúl Núñez de Arenas Coronado
.
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH 0/1] Add lines to `git log --graph` to separate connected regions
@ 2024-04-07 5:37 4% ` Junio C Hamano
2024-04-07 6:40 4% ` Quang Lê Duy
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2024-04-07 5:37 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Lê Duy Quang, git
Eric Sunshine <sunshine@sunshineco.com> writes:
>> This leads to a problem. Say there are two connected regions, each having two
>> commits, the graph would look like this:
>>
>> * a2
>> * a1
>> * b2
>> * b1
>>
>> which may lead to a misunderstanding that these four commits belong to the same
>> timeline, i.e. b2 is a parent of a1.
>>
>> This patchset adds a separator line between each pair of connected regions to
>> clarify that they are not actually connected:
>>
>> * a2
>> * a1
>> ---
>> * b2
>> * b1
>
> This sort of information which explains why the patch may be desirable
> is not only helpful to reviewers of the submission, but will be
> helpful to future readers of the patch once it becomes part of the
> project's permanent history (assuming it is accepted). However, the
> cover letter does not become part of the project's history (it exists
> only in the mailing list). As such, please move this discussion into
> the commit message of the patch itself.
True. But because we are doing graph, shouldn't we be able to do
better? For example, you can draw the two lineage of histories
on different columns and ...
* a2
* a1
* b2
* b1
... that way, you do not need to lose one line of precious vertical
screen real estate.
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH 0/1] Add lines to `git log --graph` to separate connected regions
2024-04-07 5:37 4% ` Junio C Hamano
@ 2024-04-07 6:40 4% ` Quang Lê Duy
0 siblings, 0 replies; 200+ results
From: Quang Lê Duy @ 2024-04-07 6:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Apr 7, 2024 at 12:37 PM Junio C Hamano <gitster@pobox.com> wrote:
> True. But because we are doing graph, shouldn't we be able to do
> better? For example, you can draw the two lineage of histories
> on different columns and ...
>
> * a2
> * a1
> * b2
> * b1
>
> ... that way, you do not need to lose one line of precious vertical
> screen real estate.
I think horizontal screen real estate is even more precious than the vertical
one, since one usually doesn't scroll their terminal horizontally. And then it
would probably be a way more complicated implementation.
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH] Introduce "precious" file concept
2018-11-12 16:07 5% ` Duy Nguyen
@ 2018-11-12 9:49 4% ` Ævar Arnfjörð Bjarmason
1 sibling, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-11-12 9:49 UTC (permalink / raw)
To: Matthieu Moy
Cc: Per Lundberg, Duy Nguyen, Git Mailing List, jost, Joshua Jensen,
Junio C Hamano, Clemens Buchacher, Holger Hellmuth (IKS),
Kevin Ballard
On Mon, Nov 12 2018, Matthieu Moy wrote:
> "Per Lundberg" <per.lundberg@hibox.tv> wrote:
>
>> On 11/11/18 5:41 PM, Duy Nguyen wrote:
>> > On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
>> > <avarab@gmail.com> wrote:
>>
>> >> That will lose no data, and in the very rare cases where a checkout of
>> >> tracked files would overwrite an ignored pattern, we can just error out
>> >> (as we do with the "Ok to overwrite" branch removed) and tell the user
>> >> to delete the files to proceed.
>> > There's also the other side of the coin. If this refuse to overwrite
>> > triggers too often, it can become an annoyance.
>
> I may have missed some cases, but to me the cases when checkout may try
> to overwrite an ignored file are essentially:
>
> * Someone "git add"ed a file meant to be ignored by mistake (e.g.
> "git add -f *.o").
>
> * A file that was meant to be kept private (e.g. config.mak.dev) ends
> up being tracked. This may happen when we find a way to make per-developer
> settings the same for everyone.
Yes, the cases under discussion here are all cases where a tracked file
clobbers a file matching a pattern in in .gitignore.
What I'd add to your list is:
* Some projects (I've seen this in the wild) add e.g. *.mp3 or whatever
else usually doesn't belong in the repo as a "soft ignore". This is
something we've never recommended, but have implicitly supported since
the only caveats are a) you need a one-off "git add -f" and then
they're tracked b) them being missing from "status" before being
tracked c) the issue under discussion here.
* Cases where e.g. filename changes to a directory or globs because of
that make this more complex.
> I both cases I'd want at least to be notified that something is going on,
> and in the second I'd probably want to keep my local file around.
>> If we feel thrashable is stretching it too far (which I don't think it
>> is), we could add a "core.ignore_files_are_trashable" setting that
>> brings back the old semantics, for those who have a strong feeling about it.
>
> May I remind an idea I sugested in an old thread: add an intermediate level
> where ignored files to be overwritten are renamed (eg. foo -> foo~ like Emacs'
> backup files):
>
> https://public-inbox.org/git/vpqd3t9656k.fsf@bauges.imag.fr/
>
> One advantage of the "rename" behavior is that it's safer that the current,
> but still not very disturbing for people who like the current behavior. This
> makes it a good candidate for a default behavior.
>
> This could come in complement with this thread's "precious" concept:
>
> * If you know what you're doing and know that such or such file is precious,
> mark it as such and Git will never overwrite it.
>
> * If you don't know about precious files, just keep the default setting and
> the worse that can happen is to get your file overwritten with a bakup
> of the old version kept around.
>
> This would probably play better with a notion of "precious" files than with
> a notion of "trashable" files.
I used to think this foo -> foo~ approach made the most sense (and said
as much in
https://public-inbox.org/git/871s8qdzph.fsf@evledraar.gmail.com/) but I
think it's probably best not to do it and just error out, because:
* We'd still need to handle the cases where "tests" the file collides
with "tests" the directory. Then where do we move the colliding file?
~/.git/lost+found/* ? We could handle the subdir case with another
special-case though...
* I think such silent action will just leave users more confused, and
in many cases (e.g. a merge) whatever message we print out will be
missed in a deluge of other messaging, and they'll probably miss it.
I'd like to avoid a case where a bunch of *~ files get committed
because the user's workflow is (and some beginner git users do this):
git pull && git add . && git commit && git push
As the "pull" would now invoke a merge that would do this rename.
* If I have the "foo" file open in my editor (a plausible way to run
into this) I switch to another terminal, do the merge, miss the
message, then re-save "foo". Now I have both "foo" and "foo~"
on-disk. Another case where we should just refuse until the user
resolves the situation to avoid the confusion.
^ permalink raw reply [relevance 4%]
* [PATCH v2 0/6] Fix various issues around removal of untracked files/directories
@ 2021-09-24 6:37 4% ` Elijah Newren via GitGitGadget
0 siblings, 1 reply; 200+ results
From: Elijah Newren via GitGitGadget @ 2021-09-24 6:37 UTC (permalink / raw)
To: git
Cc: Ævar Arnfjörð Bjarmason, Fedor Biryukov,
Philip Oakley, Phillip Wood, Elijah Newren, Elijah Newren
This series depends on en/am-abort-fix.
We have multiple codepaths that delete untracked files/directories but
shouldn't. There are also some codepaths where we delete untracked
files/directories intentionally (based on mailing list discussion), but
where that intent is not documented. Fix the documentation, add several new
(mostly failing) testcases, fix some of the new testcases, and add comments
about some potential remaining problems. (I found these as a side-effect of
looking at [1], though [2] pointed out one explicitly while I was working on
it.)
Note that I'm using Junio's declaration about checkout -f and reset --hard
(and also presuming that since read-tree --reset is porcelain that its
behavior should be left alone)[3] in this series.
Changes since v1:
* Various small cleanups (suggested by Ævar)
* Fixed memory leaks of unpack_trees_opts->dir (also suggested by Ævar)
* Use an enum for unpack_trees_options->reset, instead of multiple fields
(suggested by Phillip)
* Avoid changing behavior for cases not setting unpack_trees_options.reset
> 0 (even if it may make sense to nuke ignored files when running either
read-tree -m -u or the various reset flavors run internally by
rebase/sequencer); we can revisit that later.
SIDENOTE about treating (some) ignored files as precious:
There's another related topic here that came up in the mailing list threads
that is separate even if similar: namely, treating ignored files as precious
instead of deleting them. I do not try to handle that here, but I believe
that would actually be relatively easy to handle. If you leave
unpack_trees_options->dir as NULL, then ignored files are treated as
precious (my original patch 2 made that mistake). There's a few other
locations that already optionally set up unpack_trees_options->dir (a quick
search for "overwrite_ignore" and "overwrite-ignore" will find them), so
we'd just need to implement that option flag in more places corresponding to
the new callsites (and perhaps make a global core.overwrite_ignored config
option to affect all of these). Of course, doing so would globally treat
ignored files as precious rather than allowing them to be configured on a
per-path basis, but honestly I think the idea of configuring ignored files
as precious on a per-path basis sounds like insanity. (We have enough bugs
with untracked and ignored files without adding yet another type. Also,
tla/baz was excessively confusing to me due in part to the number of types
of files and I'd rather not see such ideas ported to git. And, of course,
configuring per-path rules sounds like lots of work for end users to
configure. There may be additional reasons against it.) So, if someone wants
to pursue the precious-ignored concept then I'd much rather see it done as a
global setting. Just my $0.02.
[1] https://lore.kernel.org/git/xmqqv93n7q1v.fsf@gitster.g/ [2]
https://lore.kernel.org/git/C357A648-8B13-45C3-9388-C0C7F7D40DAE@gmail.com/
[3] https://lore.kernel.org/git/xmqqr1e2ejs9.fsf@gitster.g/
Elijah Newren (6):
t2500: add various tests for nuking untracked files
Change unpack_trees' 'reset' flag into an enum
unpack-trees: avoid nuking untracked dir in way of unmerged file
unpack-trees: avoid nuking untracked dir in way of locally deleted
file
Comment important codepaths regarding nuking untracked files/dirs
Documentation: call out commands that nuke untracked files/directories
Documentation/git-checkout.txt | 5 +-
Documentation/git-read-tree.txt | 5 +-
Documentation/git-reset.txt | 3 +-
builtin/am.c | 13 +-
builtin/checkout.c | 18 ++-
builtin/read-tree.c | 3 +
builtin/reset.c | 20 ++-
builtin/stash.c | 18 ++-
builtin/submodule--helper.c | 4 +
builtin/worktree.c | 5 +
contrib/rerere-train.sh | 2 +-
reset.c | 13 +-
submodule.c | 1 +
t/t2500-untracked-overwriting.sh | 244 +++++++++++++++++++++++++++++++
unpack-trees.c | 44 +++++-
unpack-trees.h | 11 +-
16 files changed, 387 insertions(+), 22 deletions(-)
create mode 100755 t/t2500-untracked-overwriting.sh
base-commit: c5ead19ea282a288e01d86536349a4ae4a093e4b
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1036%2Fnewren%2Funtracked_removal-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1036/newren/untracked_removal-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1036
Range-diff vs v1:
1: b634136a74b ! 1: 9460a49c7ed t2500: add various tests for nuking untracked files
@@ t/t2500-untracked-overwriting.sh (new)
+. ./test-lib.sh
+
+test_setup_reset () {
-+ test_create_repo reset_$1 &&
++ git init reset_$1 &&
+ (
+ cd reset_$1 &&
+ test_commit init &&
@@ t/t2500-untracked-overwriting.sh (new)
+
+ test_must_fail git reset --merge work 2>error &&
+ test_cmp expect foo.t/file &&
-+ grep "Updating.*foo.t.*would lose untracked files" error
++ grep "Updating .foo.t. would lose untracked files" error
+ )
+'
+
@@ t/t2500-untracked-overwriting.sh (new)
+'
+
+test_setup_checkout_m () {
-+ test_create_repo checkout &&
++ git init checkout &&
+ (
+ cd checkout &&
+ test_commit init &&
@@ t/t2500-untracked-overwriting.sh (new)
+'
+
+test_setup_sequencing () {
-+ test_create_repo sequencing_$1 &&
++ git init sequencing_$1 &&
+ (
+ cd sequencing_$1 &&
+ test_commit init &&
2: 45bd05a945f ! 2: b77692b8f49 Split unpack_trees 'reset' flag into two for untracked handling
@@ Metadata
Author: Elijah Newren <newren@gmail.com>
## Commit message ##
- Split unpack_trees 'reset' flag into two for untracked handling
+ Change unpack_trees' 'reset' flag into an enum
Traditionally, unpack_trees_options->reset was used to signal that it
was okay to delete any untracked files in the way. This was used by
`git read-tree --reset`, but then started appearing in other places as
well. However, many of the other uses should not be deleting untracked
- files in the way. Split this into two separate fields:
- reset_nuke_untracked
- reset_keep_untracked
- and, since many code paths in unpack_trees need to be followed for both
- of these flags, introduce a third one for convenience:
- reset_either
- which is simply an or-ing of the other two.
+ files in the way. Change this value to an enum so that a value of 1
+ (i.e. "true") can be split into two:
+ UNPACK_RESET_PROTECT_UNTRACKED,
+ UNPACK_RESET_OVERWRITE_UNTRACKED
+ In order to catch accidental misuses, define with the enum a special
+ value of
+ UNPACK_RESET_INVALID = 1
+ which will trigger a BUG().
Modify existing callers so that
read-tree --reset
reset --hard
checkout --force
- continue using reset_nuke_untracked, but so that other callers,
- including
+ continue using the UNPACK_RESET_OVERWRITE_UNTRACKED logic, while other
+ callers, including
am
checkout without --force
stash (though currently dead code; reset always had a value of 0)
numerous callers from rebase/sequencer to reset_head()
- will use the new reset_keep_untracked field.
+ will use the new UNPACK_RESET_PROTECT_UNTRACKED value.
+
+ In order to protect untracked files but still allow deleting of ignored
+ files, we also have to setup unpack_trees_opt.dir. It may make sense to
+ set up unpack_trees_opt.dir in more cases, but here I tried to only do
+ so in cases where we switched from deleting all untracked files to
+ avoiding doing so (i.e. where we now use
+ UNPACK_RESET_PROTECT_UNTRACKED).
+
+ Also, note that 'git checkout <pathspec>' currently also allows
+ overwriting untracked files. That case should also be fixed, but it
+ does not use unpack_trees() and thus is outside the scope of the current
+ changes.
Signed-off-by: Elijah Newren <newren@gmail.com>
@@ builtin/am.c: static int fast_forward_to(struct tree *head, struct tree *remote,
opts.update = 1;
opts.merge = 1;
- opts.reset = reset;
-+ opts.reset_keep_untracked = reset;
++ opts.reset = reset ? UNPACK_RESET_PROTECT_UNTRACKED : 0;
opts.fn = twoway_merge;
-+ /* Setup opts.dir so that ignored files in the way get overwritten */
-+ opts.dir = xcalloc(1, sizeof(*opts.dir));
-+ opts.dir->flags |= DIR_SHOW_IGNORED;
-+ setup_standard_excludes(opts.dir);
++ if (opts.reset) {
++ /* Allow ignored files in the way to get overwritten */
++ opts.dir = xcalloc(1, sizeof(*opts.dir));
++ opts.dir->flags |= DIR_SHOW_IGNORED;
++ setup_standard_excludes(opts.dir);
++ }
init_tree_desc(&t[0], head->buffer, head->size);
init_tree_desc(&t[1], remote->buffer, remote->size);
+@@ builtin/am.c: static int fast_forward_to(struct tree *head, struct tree *remote, int reset)
+ return -1;
+ }
+
++ if (opts.reset) {
++ dir_clear(opts.dir);
++ FREE_AND_NULL(opts.dir);
++ }
++
+ if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
+ die(_("unable to write new index file"));
+
## builtin/checkout.c ##
@@ builtin/checkout.c: static int reset_tree(struct tree *tree, const struct checkout_opts *o,
+ {
+ struct unpack_trees_options opts;
+ struct tree_desc tree_desc;
++ int unpack_trees_ret;
+
+ memset(&opts, 0, sizeof(opts));
opts.head_idx = -1;
opts.update = worktree;
opts.skip_unmerged = !worktree;
- opts.reset = 1;
-+ if (o->force)
-+ opts.reset_nuke_untracked = 1;
-+ else
-+ opts.reset_keep_untracked = 1;
++ opts.reset = o->force ? UNPACK_RESET_OVERWRITE_UNTRACKED :
++ UNPACK_RESET_PROTECT_UNTRACKED;
opts.merge = 1;
opts.fn = oneway_merge;
opts.verbose_update = o->show_progress;
@@ builtin/checkout.c: static int reset_tree(struct tree *tree, const struct checko
init_checkout_metadata(&opts.meta, info->refname,
info->commit ? &info->commit->object.oid : null_oid(),
NULL);
+ parse_tree(tree);
+ init_tree_desc(&tree_desc, tree->buffer, tree->size);
+- switch (unpack_trees(1, &tree_desc, &opts)) {
++ unpack_trees_ret = unpack_trees(1, &tree_desc, &opts);
++
++ if (o->overwrite_ignore) {
++ dir_clear(opts.dir);
++ FREE_AND_NULL(opts.dir);
++ }
++
++ switch (unpack_trees_ret) {
+ case -2:
+ *writeout_error = 1;
+ /*
## builtin/read-tree.c ##
@@ builtin/read-tree.c: int cmd_read_tree(int argc, const char **argv, const char *cmd_prefix)
- N_("3-way merge if no file level merging required")),
- OPT_BOOL(0, "aggressive", &opts.aggressive,
- N_("3-way merge in presence of adds and removes")),
-- OPT_BOOL(0, "reset", &opts.reset,
-+ OPT_BOOL(0, "reset", &opts.reset_keep_untracked,
- N_("same as -m, but discard unmerged entries")),
- { OPTION_STRING, 0, "prefix", &opts.prefix, N_("<subdirectory>/"),
- N_("read the tree into the index under <subdirectory>/"),
-@@ builtin/read-tree.c: int cmd_read_tree(int argc, const char **argv, const char *cmd_prefix)
- opts.head_idx = -1;
- opts.src_index = &the_index;
- opts.dst_index = &the_index;
-+ if (opts.reset_keep_untracked) {
-+ opts.dir = xcalloc(1, sizeof(*opts.dir));
-+ opts.dir->flags |= DIR_SHOW_IGNORED;
-+ setup_standard_excludes(opts.dir);
-+ }
-
- git_config(git_read_tree_config, NULL);
-
-@@ builtin/read-tree.c: int cmd_read_tree(int argc, const char **argv, const char *cmd_prefix)
- hold_locked_index(&lock_file, LOCK_DIE_ON_ERROR);
-
- prefix_set = opts.prefix ? 1 : 0;
-- if (1 < opts.merge + opts.reset + prefix_set)
-+ if (1 < opts.merge + opts.reset_keep_untracked + prefix_set)
+ if (1 < opts.merge + opts.reset + prefix_set)
die("Which one? -m, --reset, or --prefix?");
++ if (opts.reset)
++ opts.reset = UNPACK_RESET_OVERWRITE_UNTRACKED;
++
/*
-@@ builtin/read-tree.c: int cmd_read_tree(int argc, const char **argv, const char *cmd_prefix)
- * mode.
- */
-
-- if (opts.reset || opts.merge || opts.prefix) {
-+ if (opts.reset_keep_untracked || opts.merge || opts.prefix) {
- if (read_cache_unmerged() && (opts.prefix || opts.merge))
- die(_("You need to resolve your current index first"));
- stage = opts.merge = 1;
+ * NEEDSWORK
+ *
## builtin/reset.c ##
@@
@@ builtin/reset.c: static int reset_index(const char *ref, const struct object_id
case HARD:
opts.update = 1;
- /* fallthrough */
-+ opts.reset_nuke_untracked = 1;
++ opts.reset = UNPACK_RESET_OVERWRITE_UNTRACKED;
+ break;
+ case MIXED:
-+ opts.reset_keep_untracked = 1; /* but opts.update=0, so untracked left alone */
++ opts.reset = UNPACK_RESET_PROTECT_UNTRACKED;
++ /* but opts.update=0, so working tree not updated */
+ break;
default:
- opts.reset = 1;
+ BUG("invalid reset_type passed to reset_index");
+ }
-+ if (opts.reset_keep_untracked) {
++ if (opts.reset == UNPACK_RESET_PROTECT_UNTRACKED) {
+ /* Setup opts.dir so we can overwrite ignored files */
+ opts.dir = xcalloc(1, sizeof(*opts.dir));
+ opts.dir->flags |= DIR_SHOW_IGNORED;
@@ builtin/reset.c: static int reset_index(const char *ref, const struct object_id
}
read_cache_unmerged();
+@@ builtin/reset.c: static int reset_index(const char *ref, const struct object_id *oid, int reset_t
+ ret = 0;
+
+ out:
++ if (opts.reset == UNPACK_RESET_PROTECT_UNTRACKED) {
++ dir_clear(opts.dir);
++ FREE_AND_NULL(opts.dir);
++ }
+ for (i = 0; i < nr; i++)
+ free((void *)desc[i].buffer);
+ return ret;
## builtin/stash.c ##
+@@ builtin/stash.c: static int reset_tree(struct object_id *i_tree, int update, int reset)
+ struct tree_desc t[MAX_UNPACK_TREES];
+ struct tree *tree;
+ struct lock_file lock_file = LOCK_INIT;
++ int unpack_trees_ret;
+
+ read_cache_preload(NULL);
+ if (refresh_cache(REFRESH_QUIET))
@@ builtin/stash.c: static int reset_tree(struct object_id *i_tree, int update, int reset)
opts.src_index = &the_index;
opts.dst_index = &the_index;
opts.merge = 1;
- opts.reset = reset;
-+ opts.reset_keep_untracked = reset;
++ opts.reset = reset ? UNPACK_RESET_PROTECT_UNTRACKED : 0;
++ if (opts.reset) {
++ opts.dir = xcalloc(1, sizeof(*opts.dir));
++ opts.dir->flags |= DIR_SHOW_IGNORED;
++ setup_standard_excludes(opts.dir);
++ }
opts.update = update;
opts.fn = oneway_merge;
+- if (unpack_trees(nr_trees, t, &opts))
++ unpack_trees_ret = unpack_trees(nr_trees, t, &opts);
++
++ if (opts.reset) {
++ dir_clear(opts.dir);
++ FREE_AND_NULL(opts.dir);
++ }
++
++ if (unpack_trees_ret)
+ return -1;
+
+ if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
## reset.c ##
@@
@@ reset.c: int reset_head(struct repository *r, struct object_id *oid, const char
- if (!detach_head)
- unpack_tree_opts.reset = 1;
+ if (!detach_head) {
-+ unpack_tree_opts.reset_keep_untracked = 1;
++ unpack_tree_opts.reset = UNPACK_RESET_PROTECT_UNTRACKED;
+ unpack_tree_opts.dir = xcalloc(1, sizeof(*unpack_tree_opts.dir));
+ unpack_tree_opts.dir->flags |= DIR_SHOW_IGNORED;
+ setup_standard_excludes(unpack_tree_opts.dir);
@@ reset.c: int reset_head(struct repository *r, struct object_id *oid, const char
if (repo_read_index_unmerged(r) < 0) {
ret = error(_("could not read index"));
-
- ## t/t1013-read-tree-submodule.sh ##
-@@ t/t1013-read-tree-submodule.sh: KNOWN_FAILURE_SUBMODULE_OVERWRITE_IGNORED_UNTRACKED=1
-
- test_submodule_switch_recursing_with_args "read-tree -u -m"
-
--test_submodule_forced_switch_recursing_with_args "read-tree -u --reset"
-+test_submodule_switch_recursing_with_args "read-tree -u --reset"
+@@ reset.c: reset_head_refs:
+ oid_to_hex(oid), "1", NULL);
- test_submodule_switch "read-tree -u -m"
-
--test_submodule_forced_switch "read-tree -u --reset"
-+test_submodule_switch "read-tree -u --reset"
-
- test_done
+ leave_reset_head:
++ if (unpack_tree_opts.dir) {
++ dir_clear(unpack_tree_opts.dir);
++ FREE_AND_NULL(unpack_tree_opts.dir);
++ }
+ strbuf_release(&msg);
+ rollback_lock_file(&lock);
+ clear_unpack_trees_porcelain(&unpack_tree_opts);
## t/t2500-untracked-overwriting.sh ##
@@ t/t2500-untracked-overwriting.sh: test_setup_checkout_m () {
@@ t/t2500-untracked-overwriting.sh: test_expect_failure 'git rebase --abort and un
cd sequencing_rebase_fast_forward_and_untracked &&
## unpack-trees.c ##
-@@ unpack-trees.c: static int check_submodule_move_head(const struct cache_entry *ce,
- if (!sub)
- return 0;
-
-- if (o->reset)
-+ if (o->reset_nuke_untracked)
- flags |= SUBMODULE_MOVE_HEAD_FORCE;
-
- if (submodule_move_head(ce->name, old_id, new_id, flags))
@@ unpack-trees.c: int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
- if (len > MAX_UNPACK_TREES)
- die("unpack_trees takes at most %d trees", MAX_UNPACK_TREES);
+ struct pattern_list pl;
+ int free_pattern_list = 0;
-+ if (o->reset_nuke_untracked && o->reset_keep_untracked)
-+ BUG("reset_nuke_untracked and reset_keep_untracked are incompatible");
++ if (o->reset == UNPACK_RESET_INVALID)
++ BUG("o->reset had a value of 1; should be UNPACK_TREES_*_UNTRACKED");
+
-+ o->reset_either = 0;
-+ if (o->reset_nuke_untracked || o->reset_keep_untracked)
-+ o->reset_either = 1;
-+
- trace_performance_enter();
- trace2_region_enter("unpack_trees", "unpack_trees", the_repository);
-
-@@ unpack-trees.c: static int verify_uptodate_1(const struct cache_entry *ce,
- */
- if ((ce->ce_flags & CE_VALID) || ce_skip_worktree(ce))
- ; /* keep checking */
-- else if (o->reset || ce_uptodate(ce))
-+ else if (o->reset_either || ce_uptodate(ce))
- return 0;
+ if (len > MAX_UNPACK_TREES)
+ die("unpack_trees takes at most %d trees", MAX_UNPACK_TREES);
- if (!lstat(ce->name, &st)) {
@@ unpack-trees.c: static int verify_absent_1(const struct cache_entry *ce,
int len;
struct stat st;
- if (o->index_only || o->reset || !o->update)
-+ if (o->index_only || o->reset_nuke_untracked || !o->update)
++ if (o->index_only || !o->update ||
++ o->reset == UNPACK_RESET_OVERWRITE_UNTRACKED)
return 0;
len = check_leading_path(ce->name, ce_namelen(ce), 0);
-@@ unpack-trees.c: int twoway_merge(const struct cache_entry * const *src,
-
- if (current) {
- if (current->ce_flags & CE_CONFLICTED) {
-- if (same(oldtree, newtree) || o->reset) {
-+ if (same(oldtree, newtree) || o->reset_either) {
- if (!newtree)
- return deleted_entry(current, current, o);
- else
-@@ unpack-trees.c: int oneway_merge(const struct cache_entry * const *src,
-
- if (old && same(old, a)) {
- int update = 0;
-- if (o->reset && o->update && !ce_uptodate(old) && !ce_skip_worktree(old) &&
-+ if (o->reset_either && o->update && !ce_uptodate(old) && !ce_skip_worktree(old) &&
- !(old->ce_flags & CE_FSMONITOR_VALID)) {
- struct stat st;
- if (lstat(old->name, &st) ||
## unpack-trees.h ##
@@ unpack-trees.h: void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
+ */
void clear_unpack_trees_porcelain(struct unpack_trees_options *opts);
++enum unpack_trees_reset_type {
++ UNPACK_RESET_NONE = 0, /* traditional "false" value; still valid */
++ UNPACK_RESET_INVALID = 1, /* "true" no longer valid; use below values */
++ UNPACK_RESET_PROTECT_UNTRACKED,
++ UNPACK_RESET_OVERWRITE_UNTRACKED
++};
++
struct unpack_trees_options {
- unsigned int reset,
-+ unsigned int reset_nuke_untracked,
-+ reset_keep_untracked,
-+ reset_either, /* internal use only */
- merge,
+- merge,
++ unsigned int merge,
update,
clone,
+ index_only,
+@@ unpack-trees.h: struct unpack_trees_options {
+ exiting_early,
+ show_all_errors,
+ dry_run;
++ enum unpack_trees_reset_type reset;
+ const char *prefix;
+ int cache_bottom;
+ struct dir_struct *dir;
3: a69117a1c9e = 3: 208f3b3ebe5 unpack-trees: avoid nuking untracked dir in way of unmerged file
4: 01bf850bb0f ! 4: 0a0997d081b unpack-trees: avoid nuking untracked dir in way of locally deleted file
@@ unpack-trees.c: static int deleted_entry(const struct cache_entry *ce,
if (verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_REMOVED, o))
return -1;
return 0;
-+ } else {
-+ if (verify_absent_if_directory(ce, ERROR_WOULD_LOSE_UNTRACKED_REMOVED, o))
-+ return -1;
++ } else if (verify_absent_if_directory(ce, ERROR_WOULD_LOSE_UNTRACKED_REMOVED, o)) {
++ return -1;
}
+
if (!(old->ce_flags & CE_CONFLICTED) && verify_uptodate(old, o))
5: 60c5d6b4615 = 5: 4b78a526d2a Comment important codepaths regarding nuking untracked files/dirs
6: 6ea23d165cf = 6: 993451a8036 Documentation: call out commands that nuke untracked files/directories
--
gitgitgadget
^ permalink raw reply [relevance 4%]
* [PATCH 24/29] ref_transaction_update(): check refname_is_safe() at a minimum
@ 2016-04-27 16:57 5% ` Michael Haggerty
0 siblings, 0 replies; 200+ results
From: Michael Haggerty @ 2016-04-27 16:57 UTC (permalink / raw)
To: git, David Turner
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy, Jeff King,
Ramsay Jones, Michael Haggerty
If the user has asked that a new value be set for a reference, we use
check_refname_format() to verify that the reference name satisfies all
of the rules. But in other cases, at least check that refname_is_safe().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
There are remaining problems in this area of the code. For example,
check_refname_format() is *less* strict than refname_is_safe(). It
allows almost arbitrary top-level reference names like "foo" and
"refs". (The latter is especially fun because if you manage to create
a reference called "refs", Git stops recognizing the directory as a
Git repository.) On the other hand, some callers call
check_refname_format() with incomplete reference names (e.g., branch
names like "master"), so the functions can't be made stricter until
those callers are changed.
I'll address these problems separately if I find the time.
refs.c | 5 +++--
t/t1400-update-ref.sh | 2 +-
t/t1430-bad-ref-name.sh | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 858b6d7..41eb9e2 100644
--- a/refs.c
+++ b/refs.c
@@ -802,8 +802,9 @@ int ref_transaction_update(struct ref_transaction *transaction,
if ((flags & REF_ISPRUNING) && !(flags & REF_NODEREF))
die("BUG: REF_ISPRUNING set without REF_NODEREF");
- if (new_sha1 && !is_null_sha1(new_sha1) &&
- check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ if ((new_sha1 && !is_null_sha1(new_sha1)) ?
+ check_refname_format(refname, REFNAME_ALLOW_ONELEVEL) :
+ !refname_is_safe(refname)) {
strbuf_addf(err, "refusing to update ref with bad name '%s'",
refname);
return -1;
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 40b0cce..08bd8fd 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -23,7 +23,7 @@ test_expect_success setup '
m=refs/heads/master
n_dir=refs/heads/gu
n=$n_dir/fixes
-outside=foo
+outside=refs/foo
test_expect_success \
"create $m" \
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index 25ddab4..8937e25 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@ -285,7 +285,7 @@ test_expect_success 'update-ref -d cannot delete non-ref in .git dir' '
echo precious >expect &&
test_must_fail git update-ref -d my-private-file >output 2>error &&
test_must_be_empty output &&
- test_i18ngrep -e "cannot lock .*: unable to resolve reference" error &&
+ test_i18ngrep -e "refusing to update ref with bad name" error &&
test_cmp expect .git/my-private-file
'
--
2.8.1
^ permalink raw reply related [relevance 5%]
* Re: Trouble testing out a patch on a branch new scratch git.git repository
@ 2009-02-08 21:46 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2009-02-08 21:46 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
Brent Goodrick <bgoodr@gmail.com> writes:
> So, here is what I think happened in my repo:
>
> 1. A while ago, I made some changes and began testing them out.
> 2. I committed the change into the first commit (see
> e802880bb89524b1f70132f1ca0716624788db3f below)
> 3. Unfortunately, I then stumbled across the coding guidelines, and
> then discovered that my if statements had too many curly braces, and
> fixed that with another commit (but I doubt that is the problem here)
> 4. I did a git pull origin and found a conflict in a file I had
> changed in the first commit above into cache.h (I had inserted a line
> right where someone else had inserted a line). I probably should have
> stopped right then and there and not gone ahead with the merge, but do
> something different (but if so, then what should I have done instead?)
> :)
Your work is about adding this new feature. Use a topic branch.
Now what is that topic branch is for? Yes, it is about adding this new
feature, and nothing else. Don't pull other people's changes made on my
tree into it. That will make your topic branch "one new feature and
everything else" and useless as a topic branch.
What would make your life easier would be:
$ git pull ;# to get up to date with me on your master branch
$ git checkout -b bg/no-progress origin/master
... work on e802880 ...
... test it ...
$ git commit ;# record that on bg/no-progress topic
$ git checkout master
$ git merge bg/no-progress
... test the result of the merge ...
$ git checkout bg/no-progress
... work on style fix ...
... test it ...
$ git commit ;# again record it on bg/no-progress topic
$ git checkout master
$ git merge bg/no-progress
... test the result of the merge ...
$ git pull ;# to get up to date with me
... resolve conflicts ...
Then after you are convinced that everything on bg/no-progress is worthy
of sending to the list [*A*], but its tip is stale because things have
progressed on my end, you can do this:
$ git checkout bg/no-progress
$ git rebase origin/master ;# and rebase to the upstream
which may conflict again (but that would be the same conflict you saw with
your "git pull" from me, and rerere may remember it).
Review and test the result and then:
$ git format-patch origin/master
There can be variants in the last few steps. For example, your commits on
bg/no-progress may be full of "Oops, this is to fix my own mistake made in
earlier commits since I forked from the upstream". You would not want to
have them in your submission (instead, you would want to pretend as if you
never made these mistakes in the first place). For that, you may want to
do, after you feel the tip of bg/no-progress is in a good shape at point
*A* above:
$ git checkout bg/no-progress
$ git rebase -i origin/master ;# and rebase to the upstream
and reorder, squash, and fix them.
Also you may feel that at point [*A*] what you have is very precious and
you would not want yourself breaking it by the final rebase (which is a
very reasonable thing to feel). In such a case, the final rewrite could
be:
$ git checkout bg/no-progress^0
$ git rebase -i origin/master ;# and rebase to the upstream
... test and review the result.
... convince yourself it is indeed better than
... what you earlier thought to be "very precious".
... and then finally
$ git branch -f bg/no-progress
$ git format-patch origin/master ;# send this
And to finish it off, you may do:
$ git checkout master
$ git merge --ours bg/no-progress
The above is a suggestion based on a design to allow you keep sticking to
your merge based workflow as much as possible, but you could instead
choose to keep rebasing. I have some observations at the end of
http://gitster.livejournal.com/24080.html
comparing the merge based workflow and the rebase based one.
^ permalink raw reply [relevance 5%]
* [PATCH v5 0/2] gc: introduce `gc.recentObjectsHook`
@ 2023-06-07 22:58 5% ` Taylor Blau
2023-05-16 0:23 5% ` [PATCH v4 " Taylor Blau
1 sibling, 0 replies; 200+ results
From: Taylor Blau @ 2023-06-07 22:58 UTC (permalink / raw)
To: git; +Cc: Jeff King, Chris Torek, Derrick Stolee, Junio C Hamano, Glen Choo
Here is a version of my series to implement the mutli-valued
"gc.recentObjectHook" configuration, which allows users to define custom
programs whose output determines an additional set of objects to retain
(along with their descendants) when GCing, regardless of their true age.
It is largely the same as the previous round, with the following
changes:
- a small handful of wordsmithing changes in the second patch's
message thanks to a very helpful review from the Google team's
"Review Club" meeting.
- removed a pair of stray references to "cruft tips" in favor of
"recent objects".
- rebased onto v2.41.0
Based on previous rounds of review, I think that this version should be
pretty much ready to go. But I'd appreciate some extra eyes on it just
to make sure.
Thanks in advance for your (hopefully final!) review.
Taylor Blau (2):
reachable.c: extract `obj_is_recent()`
gc: introduce `gc.recentObjectsHook`
Documentation/config/gc.txt | 15 +++
reachable.c | 85 ++++++++++++-
t/t5304-prune.sh | 14 +++
t/t5329-pack-objects-cruft.sh | 171 +++++++++++++++++++++++++++
t/t7701-repack-unpack-unreachable.sh | 31 +++++
5 files changed, 313 insertions(+), 3 deletions(-)
Range-diff against v4:
1: 9c1b59c8cf = 1: 38c4c4a17f reachable.c: extract `obj_is_recent()`
2: 18e50d2517 ! 2: f661b54941 gc: introduce `gc.recentObjectsHook`
@@ Commit message
be pruned. Our options today consist of:
- Point references at the reachability tips of any objects you
- consider precious, which may be undesirable or infeasible.
+ consider precious, which may be undesirable or infeasible if there
+ are many such objects.
- Track them via the reflog, which may be undesirable since the
reflog's lifetime is limited to that of the reference it's tracking
@@ Documentation/config/gc.txt: or rebase occurring. Since these changes are not p
default is more aggressive than `gc.reflogExpire`.
+gc.recentObjectsHook::
-+ When considering the recency of an object (e.g., when generating
-+ a cruft pack or storing unreachable objects as loose), use the
-+ shell to execute the specified command(s). Interpret their
-+ output as object IDs which Git will consider as "recent",
-+ regardless of their age.
++ When considering whether or not to remove an object (either when
++ generating a cruft pack or storing unreachable objects as
++ loose), use the shell to execute the specified command(s).
++ Interpret their output as object IDs which Git will consider as
++ "recent", regardless of their age. By treating their mtimes as
++ "now", any objects (and their descendants) mentioned in the
++ output will be kept regardless of their true age.
++
+Output must contain exactly one hex object ID per line, and nothing
+else. Objects which cannot be found in the repository are ignored.
@@ reachable.c: struct recent_data {
+ ret = run_one_gc_recent_objects_hook(&data->extra_recent_oids,
+ programs->items[i].string);
+ if (ret)
-+ die(_("unable to enumerate additional cruft tips"));
++ die(_("unable to enumerate additional recent objects"));
+ }
+}
+
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ # ensure that a dirty exit halts cruft pack generation
+ git config --add gc.recentObjectsHook ./extra-tips.c &&
+ test_must_fail git repack --cruft --cruft-expiration=now -d 2>err &&
-+ grep "unable to enumerate additional cruft tips" err &&
++ grep "unable to enumerate additional recent objects" err &&
+
+ # and that the existing cruft pack is left alone
+ test_path_is_file "$mtimes"
--
2.41.0.2.gaaae24b3a6.dirty
^ permalink raw reply [relevance 5%]
* Re: [RFC/PATCH v11 13/13] bisect--helper: `bisect_start` shell function partially in C
@ 2016-08-02 20:19 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2016-08-02 20:19 UTC (permalink / raw)
To: Pranit Bauva; +Cc: git
Pranit Bauva <pranit.bauva@gmail.com> writes:
> +static int bisect_start(struct bisect_terms *terms, int no_checkout,
> + const char **argv, int argc)
> +{
> + int i, j, has_double_dash = 0, must_write_terms = 0, bad_seen = 0;
> + int flag;
> + struct string_list revs = STRING_LIST_INIT_DUP;
> + struct string_list states = STRING_LIST_INIT_DUP;
> + struct strbuf start_head = STRBUF_INIT;
> + const char *head;
> + unsigned char sha1[20];
> + FILE *fp;
> + struct object_id oid;
> +
> + if (is_bare_repository())
> + no_checkout = 1;
> +
> + for(i = 0; i < argc; i++) {
SP after for.
> + if (!strcmp(argv[i], "--")) {
> + has_double_dash = 1;
> + break;
> + }
> + if (!strcmp(argv[i], "--term-good")) {
> + must_write_terms = 1;
> + strbuf_reset(&terms->term_good);
> + strbuf_addstr(&terms->term_good, argv[++i]);
> + break;
> + }
> + if (!strcmp(argv[i], "--term-bad")) {
> + must_write_terms = 1;
> + strbuf_reset(&terms->term_bad);
> + strbuf_addstr(&terms->term_bad, argv[++i]);
> + break;
> + }
The original was not careful, either, but what if the user ends the
command line with "--term-good", without anything after it?
Also the original is prepared to handle --term-good=boa; because
this function can be be called directly from the UI (i.e. "git
bisect start --term-good=boa"), not supporting that form would be
seen as a regression.
> + if (starts_with(argv[i], "--") &&
> + !one_of(argv[i], "--term-good", "--term-bad", NULL)) {
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + die(_("unrecognised option: '%s'"), argv[i]);
> + }
> + if (get_oid(argv[i], &oid) || has_double_dash) {
Calling get_oid() alone is insufficient to make sure argv[i] refers
to an existing object that is a committish. The "^{commit}" suffix
in the original is there for a reason.
> + string_list_clear(&revs, 0);
> + string_list_clear(&revs, 0);
You seem to want the revs list really really clean ;-)
> + die(_("'%s' does not appear to be a valid revision"), argv[i]);
> + }
> + else
> + string_list_append(&revs, oid_to_hex(&oid));
> + }
> +
> + for (j = 0; j < revs.nr; j++) {
Why "j", not "i", as clearly the previous loop has finished at this
point? The only reason why replacing "j" with "i" would make this
function buggy would be if a later part of this function depended on
the value of "i" when the control left the above loop, but if that
were the case (I didn't check carefully), such a precious value that
has long term effect throughout the remainder of the function must
not be kept in an otherwise throw-away loop counter variable "i".
Introduce a new "int pathspec_pos" and set it to "i" immediately
after the "for (i = 0; i < argc; i++) { ... }" loop above, perhaps.
> + struct strbuf state = STRBUF_INIT;
> + /*
> + * The user ran "git bisect start <sha1> <sha1>", hence
> + * did not explicitly specify the terms, but we are already
> + * starting to set references named with the default terms,
> + * and won't be able to change afterwards.
> + */
> + must_write_terms = 1;
> +
> + if (bad_seen)
> + strbuf_addstr(&state, terms->term_good.buf);
> + else {
> + bad_seen = 1;
> + strbuf_addstr(&state, terms->term_bad.buf);
> + }
> + string_list_append(&states, state.buf);
> + strbuf_release(&state);
> + }
How about this instead?
/*
* that comment block goes here
*/
must_write_terms = !!revs.nr;
for (i = 0; i < revs.nr; i++) {
if (bad_seen)
string_list_append(&states, terms->term_good.buf);
else
string_list_append(&states, terms->term_bad.buf);
}
> +
> + /*
> + * Verify HEAD
> + */
> + head = resolve_ref_unsafe("HEAD", 0, sha1, &flag);
The last parameter is a set of flag bits, so call it flags.
> + if (!head) {
> + if (get_sha1("HEAD", sha1)) {
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + die(_("Bad HEAD - I need a HEAD"));
We see many repeated calls to clear these two string lists before
exiting with failure, either by dying or return -1.
I wonder how bad the resulting code would look like if we employed
the standard pattern of having a "fail_return:" label at the end of
the function (after the "return" for the usual control flow) to
clear them. If the result becomes less readable (and I suspect that
you would end up making it less readable), leaving the current code
structure is OK.
> + }
> + }
> + if (!is_empty_or_missing_file(git_path_bisect_start())) {
> + /* Reset to the rev from where we started */
> + strbuf_read_file(&start_head, git_path_bisect_start(), 0);
> + strbuf_trim(&start_head);
> + if (!no_checkout) {
> + struct argv_array argv = ARGV_ARRAY_INIT;
> + argv_array_pushl(&argv, "checkout", start_head.buf,
> + "--", NULL);
> + if (run_command_v_opt(argv.argv, RUN_GIT_CMD)) {
> + error(_("checking out '%s' failed. Try again."),
> + start_head.buf);
The original suggests to try "git bisect reset" here to recover.
> + strbuf_release(&start_head);
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + return -1;
> + }
> + }
> + } else {
> + if (starts_with(head, "refs/head/") || !get_oid(head, &oid)) {
get_oid() is insufficient to ensure what you have in $head is
40-hex. I think you meant get_oid_hex() here.
> + /*
> + * This error message should only be triggered by
> + * cogito usage, and cogito users should understand
> + * it relates to cg-seek.
> + */
> + if (!is_empty_or_missing_file(git_path_head_name())) {
> + strbuf_release(&start_head);
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + die(_("won't bisect on cg-seek'ed tree"));
> + }
> + if (starts_with(head, "refs/heads/")) {
skip_prefix(), perhaps, if "head" is no longer used from here on?
> + /*
> + * Write new start state
> + */
> + fp = fopen(git_path_bisect_start(), "w");
> + if (!fp) {
> + bisect_clean_state();
> + strbuf_release(&start_head);
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + return -1;
> + }
> + if (!fprintf(fp, "%s\n", start_head.buf)) {
man 3 fprintf and look for "Return Value"?
> + fclose(fp);
> + bisect_clean_state();
> + strbuf_release(&start_head);
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + return -1;
> + }
> + fclose(fp);
Perhaps use write_file() instead of the above block of text?
> + if (no_checkout) {
> + get_oid(start_head.buf, &oid);
> + if (update_ref(NULL, "BISECT_HEAD", oid.hash, NULL, 0,
> + UPDATE_REFS_MSG_ON_ERR)) {
Doesn't the original use --no-deref for this update-ref call?
> + bisect_clean_state();
> + strbuf_release(&start_head);
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + return -1;
> + }
> + }
> + strbuf_release(&start_head);
> + fp = fopen(git_path_bisect_names(), "w");
> +
> + for (; i < argc; i++) {
> + if (!fprintf(fp, "%s ", argv[i])) {
man 3 fprintf and look for "Return Value"?
More importantly, the original does --sq-quote so that BISECT_NAMES
file can be read back by a shell. This is important as argv[i] can
have whitespace in it, and you are concatenating them with SP in
between here. Also you are not terminating that line.
> + fclose(fp);
> + bisect_clean_state();
> + string_list_clear(&revs, 0);
> + string_list_clear(&states, 0);
> + return -1;
> + }
> + }
> + fclose(fp);
Perhaps
strbuf_reset(&bisect_names);
if (pathspec_pos < argc)
sq_quote_argv(&bisect_names, argv + pathspec_pos, 0);
write_file(git_path_bisect_names(), "%s\n", bisect_names.buf);
or something like that?
> + for (j = 0; j < states.nr; j ++) {
Again, is "i" still precious here? Style: drop SP between j and ++.
> + fp = fopen(git_path_bisect_log(), "a");
> + if (!fp) {
> + bisect_clean_state();
> + return -1;
> + }
> + if (!fprintf(fp, "git bisect start")) {
> + bisect_clean_state();
> + return -1;
> + }
> + for (i = 0; i < argc; i++) {
> + if (!fprintf(fp, " '%s'", argv[i])) {
> + fclose(fp);
> + bisect_clean_state();
> + return -1;
> + }
> + }
> + if (!fprintf(fp, "\n")) {
> + fclose(fp);
> + bisect_clean_state();
> + return -1;
> + }
Again, the original writes orig_args which was protected with --sq-quote.
> + fclose(fp);
> +
> + return 0;
> +}
> +
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 2/6] Change unpack_trees' 'reset' flag into an enum
@ 2021-09-24 17:35 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-09-24 17:35 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget
Cc: git, Ævar Arnfjörð Bjarmason, Fedor Biryukov,
Philip Oakley, Phillip Wood, Elijah Newren
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Also, note that 'git checkout <pathspec>' currently also allows
> overwriting untracked files. That case should also be fixed, ...
I wasted a few minutes wondering about the example. Please make it
clear that you are checking out of a tree-ish that is different from
HEAD, as there will by definition no "overwriting untracked" if you
are checking out of the index.
E.g. "git checkout <tree-ish> -- <pathspec>".
With this command line:
$ git checkout HEAD~24 -- path
where path used to be there as late as 24 revisions ago, but since
then we removed, and the user wants to materialize the file out of
the old version, path, be it tracked, untracked, or even a
directory, should be made identical to the copy from the given
version, no? Where does the "should also be fixed" come from?
> diff --git a/builtin/am.c b/builtin/am.c
> index c79e0167e98..b17baa67ad8 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -1918,8 +1918,14 @@ static int fast_forward_to(struct tree *head, struct tree *remote, int reset)
> opts.dst_index = &the_index;
> opts.update = 1;
> opts.merge = 1;
> - opts.reset = reset;
> + opts.reset = reset ? UNPACK_RESET_PROTECT_UNTRACKED : 0;
> opts.fn = twoway_merge;
> + if (opts.reset) {
> + /* Allow ignored files in the way to get overwritten */
> + opts.dir = xcalloc(1, sizeof(*opts.dir));
> + opts.dir->flags |= DIR_SHOW_IGNORED;
> + setup_standard_excludes(opts.dir);
Do these three lines make a recurring pattern when opts.reset is set?
I am wondering if this can be done more centrally by the unpack-trees
machinery (i.e. "gee this one has o->reset set to X, so let's set up
the o->dir before doing anything").
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index b5d477919a7..52826e0d145 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -641,23 +641,37 @@ static int reset_tree(struct tree *tree, const struct checkout_opts *o,
> {
> struct unpack_trees_options opts;
> struct tree_desc tree_desc;
> + int unpack_trees_ret;
>
> memset(&opts, 0, sizeof(opts));
> opts.head_idx = -1;
> opts.update = worktree;
> opts.skip_unmerged = !worktree;
> - opts.reset = 1;
> + opts.reset = o->force ? UNPACK_RESET_OVERWRITE_UNTRACKED :
> + UNPACK_RESET_PROTECT_UNTRACKED;
> opts.merge = 1;
> opts.fn = oneway_merge;
> opts.verbose_update = o->show_progress;
> opts.src_index = &the_index;
> opts.dst_index = &the_index;
> + if (o->overwrite_ignore) {
> + opts.dir = xcalloc(1, sizeof(*opts.dir));
> + opts.dir->flags |= DIR_SHOW_IGNORED;
> + setup_standard_excludes(opts.dir);
> + }
If our longer term goal is to decide classification of files not in
the index (currently, "ignored" and "untracked", but we may want to
add a new "precious" class) and (across various commands that build
on the unpack-trees infrastructure) to protect the "untracked" and
"precious" ones, with --[no-]overwrite-{ignore,untracked} options as
escape hatches, uniformly, perhaps the --[no-]-overwrite-ignore
option may be stolen from here and shifted to unpack_tree_options to
help us going in that direction? This is just an observation for
longer term, not a suggestion to include the first step for such a
move in this series.
> init_checkout_metadata(&opts.meta, info->refname,
> info->commit ? &info->commit->object.oid : null_oid(),
> NULL);
> parse_tree(tree);
> init_tree_desc(&tree_desc, tree->buffer, tree->size);
> - switch (unpack_trees(1, &tree_desc, &opts)) {
> + unpack_trees_ret = unpack_trees(1, &tree_desc, &opts);
> +
> + if (o->overwrite_ignore) {
> + dir_clear(opts.dir);
> + FREE_AND_NULL(opts.dir);
This dir_clear() is also a recurring theme. See below.
> + }
> +
> + switch (unpack_trees_ret) {
> case -2:
> *writeout_error = 1;
> /*
> diff --git a/builtin/read-tree.c b/builtin/read-tree.c
> index 485e7b04794..740fc0335af 100644
> --- a/builtin/read-tree.c
> +++ b/builtin/read-tree.c
> @@ -174,6 +174,9 @@ int cmd_read_tree(int argc, const char **argv, const char *cmd_prefix)
> if (1 < opts.merge + opts.reset + prefix_set)
> die("Which one? -m, --reset, or --prefix?");
>
> + if (opts.reset)
> + opts.reset = UNPACK_RESET_OVERWRITE_UNTRACKED;
> +
We do not do anything about opts.dir here by default, which means we
by default do not overwrite ignored, but that's OK, because this old
command explicitly takes --exclude-per-directory to tell it what the
command should consider "ignored" and with the option given we do
prepare opts.dir just fine.
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 43e855cb887..a12ee986e9f 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -10,6 +10,7 @@
> #define USE_THE_INDEX_COMPATIBILITY_MACROS
> #include "builtin.h"
> #include "config.h"
> +#include "dir.h"
> #include "lockfile.h"
> #include "tag.h"
> #include "object.h"
> @@ -70,9 +71,20 @@ static int reset_index(const char *ref, const struct object_id *oid, int reset_t
> break;
> case HARD:
> opts.update = 1;
> - /* fallthrough */
> + opts.reset = UNPACK_RESET_OVERWRITE_UNTRACKED;
> + break;
> + case MIXED:
> + opts.reset = UNPACK_RESET_PROTECT_UNTRACKED;
> + /* but opts.update=0, so working tree not updated */
> + break;
> default:
> - opts.reset = 1;
> + BUG("invalid reset_type passed to reset_index");
> + }
> + if (opts.reset == UNPACK_RESET_PROTECT_UNTRACKED) {
Unlike the one in "am", this cares .reset being a particular value,
not just being non-zero. Puzzling.
It is a bit counter-intuitive in that we do not allow overwrite
ignored (which is currently a synonym for "expendable") when .reset
is set to allow us to ovewrite untracked.
> + /* Setup opts.dir so we can overwrite ignored files */
> + opts.dir = xcalloc(1, sizeof(*opts.dir));
> + opts.dir->flags |= DIR_SHOW_IGNORED;
> + setup_standard_excludes(opts.dir);
> @@ -104,6 +116,10 @@ static int reset_index(const char *ref, const struct object_id *oid, int reset_t
> ret = 0;
>
> out:
> + if (opts.reset == UNPACK_RESET_PROTECT_UNTRACKED) {
> + dir_clear(opts.dir);
> + FREE_AND_NULL(opts.dir);
This dir_clear() is also a recurring theme. See below.
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 8f42360ca91..563f590afbd 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -237,6 +237,7 @@ static int reset_tree(struct object_id *i_tree, int update, int reset)
> struct tree_desc t[MAX_UNPACK_TREES];
> struct tree *tree;
> struct lock_file lock_file = LOCK_INIT;
> + int unpack_trees_ret;
>
> read_cache_preload(NULL);
> if (refresh_cache(REFRESH_QUIET))
> @@ -256,11 +257,23 @@ static int reset_tree(struct object_id *i_tree, int update, int reset)
> opts.src_index = &the_index;
> opts.dst_index = &the_index;
> opts.merge = 1;
> - opts.reset = reset;
> + opts.reset = reset ? UNPACK_RESET_PROTECT_UNTRACKED : 0;
> + if (opts.reset) {
> + opts.dir = xcalloc(1, sizeof(*opts.dir));
> + opts.dir->flags |= DIR_SHOW_IGNORED;
> + setup_standard_excludes(opts.dir);
> + }
> opts.update = update;
> opts.fn = oneway_merge;
>
> - if (unpack_trees(nr_trees, t, &opts))
> + unpack_trees_ret = unpack_trees(nr_trees, t, &opts);
> +
> + if (opts.reset) {
> + dir_clear(opts.dir);
> + FREE_AND_NULL(opts.dir);
This dir_clear() is also a recurring theme. Why aren't their guards
uniformly "if (opts.dir)"? The logic to decide if we set up opts.dir
or not may be far from here and may be different from code path to
code path, but the need to clear opts.dir should not have to care
why opts.dir was populated, no?
> + }
> +
> + if (unpack_trees_ret)
> return -1;
>
> if (write_locked_index(&the_index, &lock_file, COMMIT_LOCK))
> diff --git a/reset.c b/reset.c
> index 79310ae071b..1695f3828c5 100644
> --- a/reset.c
> +++ b/reset.c
> @@ -1,5 +1,6 @@
> #include "git-compat-util.h"
> #include "cache-tree.h"
> +#include "dir.h"
> #include "lockfile.h"
> #include "refs.h"
> #include "reset.h"
> @@ -57,8 +58,12 @@ int reset_head(struct repository *r, struct object_id *oid, const char *action,
> unpack_tree_opts.update = 1;
> unpack_tree_opts.merge = 1;
> init_checkout_metadata(&unpack_tree_opts.meta, switch_to_branch, oid, NULL);
> - if (!detach_head)
> - unpack_tree_opts.reset = 1;
> + if (!detach_head) {
> + unpack_tree_opts.reset = UNPACK_RESET_PROTECT_UNTRACKED;
> + unpack_tree_opts.dir = xcalloc(1, sizeof(*unpack_tree_opts.dir));
> + unpack_tree_opts.dir->flags |= DIR_SHOW_IGNORED;
> + setup_standard_excludes(unpack_tree_opts.dir);
> + }
>
> if (repo_read_index_unmerged(r) < 0) {
> ret = error(_("could not read index"));
> @@ -131,6 +136,10 @@ reset_head_refs:
> oid_to_hex(oid), "1", NULL);
>
> leave_reset_head:
> + if (unpack_tree_opts.dir) {
> + dir_clear(unpack_tree_opts.dir);
> + FREE_AND_NULL(unpack_tree_opts.dir);
Yes, I think this is the right way to decide if we call dir_clear(),
and all other hunks in this patch should do the same.
> + }
> strbuf_release(&msg);
> rollback_lock_file(&lock);
> clear_unpack_trees_porcelain(&unpack_tree_opts);
> diff --git a/t/t2500-untracked-overwriting.sh b/t/t2500-untracked-overwriting.sh
> index 2412d121ea8..18604360df8 100755
> --- a/t/t2500-untracked-overwriting.sh
> +++ b/t/t2500-untracked-overwriting.sh
> @@ -92,7 +92,7 @@ test_setup_checkout_m () {
> )
> }
>
> -test_expect_failure 'checkout -m does not nuke untracked file' '
> +test_expect_success 'checkout -m does not nuke untracked file' '
> test_setup_checkout_m &&
> (
> cd checkout &&
> @@ -138,7 +138,7 @@ test_setup_sequencing () {
> )
> }
>
> -test_expect_failure 'git rebase --abort and untracked files' '
> +test_expect_success 'git rebase --abort and untracked files' '
> test_setup_sequencing rebase_abort_and_untracked &&
> (
> cd sequencing_rebase_abort_and_untracked &&
> @@ -155,7 +155,7 @@ test_expect_failure 'git rebase --abort and untracked files' '
> )
> '
>
> -test_expect_failure 'git rebase fast forwarding and untracked files' '
> +test_expect_success 'git rebase fast forwarding and untracked files' '
> test_setup_sequencing rebase_fast_forward_and_untracked &&
> (
> cd sequencing_rebase_fast_forward_and_untracked &&
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 5786645f315..fcbe63bbed9 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1693,6 +1693,9 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
> struct pattern_list pl;
> int free_pattern_list = 0;
>
> + if (o->reset == UNPACK_RESET_INVALID)
> + BUG("o->reset had a value of 1; should be UNPACK_TREES_*_UNTRACKED");
> +
> if (len > MAX_UNPACK_TREES)
> die("unpack_trees takes at most %d trees", MAX_UNPACK_TREES);
>
> @@ -2218,7 +2221,8 @@ static int verify_absent_1(const struct cache_entry *ce,
> int len;
> struct stat st;
>
> - if (o->index_only || o->reset || !o->update)
> + if (o->index_only || !o->update ||
> + o->reset == UNPACK_RESET_OVERWRITE_UNTRACKED)
> return 0;
>
> len = check_leading_path(ce->name, ce_namelen(ce), 0);
> diff --git a/unpack-trees.h b/unpack-trees.h
> index 2d88b19dca7..1f386fb16cc 100644
> --- a/unpack-trees.h
> +++ b/unpack-trees.h
> @@ -45,9 +45,15 @@ void setup_unpack_trees_porcelain(struct unpack_trees_options *opts,
> */
> void clear_unpack_trees_porcelain(struct unpack_trees_options *opts);
>
> +enum unpack_trees_reset_type {
> + UNPACK_RESET_NONE = 0, /* traditional "false" value; still valid */
> + UNPACK_RESET_INVALID = 1, /* "true" no longer valid; use below values */
> + UNPACK_RESET_PROTECT_UNTRACKED,
> + UNPACK_RESET_OVERWRITE_UNTRACKED
> +};
> +
> struct unpack_trees_options {
> - unsigned int reset,
> - merge,
> + unsigned int merge,
> update,
> clone,
> index_only,
> @@ -64,6 +70,7 @@ struct unpack_trees_options {
> exiting_early,
> show_all_errors,
> dry_run;
> + enum unpack_trees_reset_type reset;
> const char *prefix;
> int cache_bottom;
> struct dir_struct *dir;
^ permalink raw reply [relevance 5%]
* Warning: fetch updated the current branch head.
@ 2006-03-22 9:48 5% Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2006-03-22 9:48 UTC (permalink / raw)
To: git
I was helping somebody who:
* had a clone of git.git repository;
* had "next" checked out a week or so ago;
* did not have any development on his own;
* tried to pull using the default .git/remotes/origin from me.
Somehow the index was out of sync before that pull but there was
no change in the working tree (i.e. just the cached stat was
different), and it refused to fast-forward the index and the
working tree, because if there _were_ real changes in the
working tree, they would have been lost by a fast-forward.
This patch will be in "next" and does two things:
* runs "git update-index --refresh" before the fast-forwarding,
to prevent stat-only difference from interfering;
* if there really is a local change in the working tree, show
the original branch head information in the message, to allow
the user to decide what to do next.
The first one would have made his working tree to fast-forward
correctly. If the fast-forward is still prevented, that means
there really was a change, and in such a case, the way to recover
would be:
* Examine "git diff $orig_head" output, to make sure there is
no local change since the last pull. If there is none, you
can run "git reset --hard" (you do not have to name "next",
because that is the branch you are already on) and you are
done.
* If there are local changes, stash them away as a patch,
"git reset --hard" and re-apply if they are precious.
I've considered rewinding the tracking branch to match
$orig_head in such a case just before "die", but that would be a
disservice to people behind a narrow pipe -- it would require
them to re-download the objects to update the branch.
I now realize that the "die" message is a bit confusing, after
writing the above recovery procedure. Especially, the new
"git-update-index --refresh" would say "foo: needs update", but
"update your working tree" does not mean "git update-index foo"
after such a failure. Maybe this phrasing is better:
die 'Cannot fast-forward your working tree.
After making sure that you saved anything precious from
$ git diff '$orig_head'
output, and run
$ git reset --hard
to recover.'
Opinions?
-- >8 --
[PATCH] git-pull: further safety while on tracking branch.
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-pull.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
cf46e7b8999f25d5d7f2acd64701a100e403ee03
diff --git a/git-pull.sh b/git-pull.sh
index 29c14e1..d90f7c9 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -55,7 +55,9 @@ then
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
- echo >&2 "Warning: fast forwarding your working tree."
+ echo >&2 "Warning: fast forwarding your working tree from"
+ echo >&2 "Warning: $orig_head commit."
+ git-update-index --refresh 2>/dev/null
git-read-tree -u -m "$orig_head" "$curr_head" ||
die "You need to first update your working tree."
fi
--
1.2.4.gfd45
^ permalink raw reply related [relevance 5%]
* [PATCH] Don't pass CFLAGS to the linker
@ 2009-12-27 6:55 5% Tomas Carnecky
0 siblings, 0 replies; 200+ results
From: Tomas Carnecky @ 2009-12-27 6:55 UTC (permalink / raw)
To: git
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
---
I don't remember exactly which tool had problems with CFLAGS being passed
to the linker. Maybe it was the clang static analyzer, or some other
tool that I let run on git.git. Anyway, I don't think there's any
reason to pass CFLAGS to the linker.
Makefile | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index c11719c..d9cd189 100644
--- a/Makefile
+++ b/Makefile
@@ -1473,8 +1473,7 @@ git.o: git.c common-cmds.h GIT-CFLAGS
$(ALL_CFLAGS) -o $@ -c $(filter %.c,$^)
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
- $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ git.o $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
@@ -1660,10 +1659,10 @@ http-walker.o: http-walker.c http.h GIT-CFLAGS
endif
git-%$X: %.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
git-imap-send$X: imap-send.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
http.o http-walker.o http-push.o: http.h
@@ -1671,14 +1670,14 @@ http.o http-walker.o http-push.o: http.h
http.o http-walker.o: $(LIB_H)
git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL)
git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
@@ -1798,7 +1797,7 @@ test-parse-options.o: parse-options.h
.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
test-%$X: test-%.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
check-sha1:: test-sha1$X
./test-sha1.sh
--
1.6.6
^ permalink raw reply related [relevance 5%]
* Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"
@ 2023-02-24 22:06 5% ` Sergey Organov
0 siblings, 0 replies; 200+ results
From: Sergey Organov @ 2023-02-24 22:06 UTC (permalink / raw)
To: Elijah Newren
Cc: Tao Klerks, phillip.wood, Alex Henrie,
Tao Klerks via GitGitGadget, git, Johannes Schindelin
Elijah Newren <newren@gmail.com> writes:
> On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Tao Klerks <tao@klerks.biz> writes:
>>
>> > On Sat, Feb 18, 2023 at 5:39 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>> >>
>> >> On 18/02/2023 03:17, Elijah Newren wrote:
>
> [...]
>
>> I also agree (in particular with Buga) that from the POV of user
>> experience the method suggested by Phillip should be superior, as it
>> emphasizes the natural dominance of the "current branch", as opposed to
>> originally described symmetric method that is more suitable for formal
>> analysis than for actual convenient implementation. Yet creating U1' and
>> U2' from the original method could be useful for the purpose of checking
>> for possible problems with automatic rebase that the user may need to be
>> aware of.
>>
>> The biggest problem here, as I see it, is designing UI that'd make sense
>> in the case of conflicts in multiple stages of the suggested algorithms,
>> but I think we can simplify it for now by stopping and suggesting blind
>> re-merge in case of any conflict but that on rebasing of changes to the
>> first parent. Even this would be a huge step forward compared to silent
>> drop of merge commits and blindly re-merging of updated parents.
>
> I'm not so sure it's a huge step forward. Or even a step forward.
Git currently throws away my precious merges! Silently! How it's not a
step forward to stop doing this?! Sorry for getting that heated :)
Git is well-known for being extremely careful with user content, and
there is the only case where it fails miserably: rebasing merges. The
above method will simply fix this long-standing deficiency that is even
more dangerous as users do trust Git so much.
I can only tell that I, for example, will definitely benefit a lot once
it is implemented, as currently a rebase containing merge is at roughly
the same level of risk as "cvs update" was in the old days: run and keep
your fingers crossed. Well, with Git it's unless you are careful to do
2-step merge-fixup thingy every time you merge, that is basically just
poor man attempt at fighting long-standing Git weakness.
> Dscho actually implemented the old proposals and tried them out, as
> mentioned in the threads I linked to. The results on balance were
> significantly worse to him than just throwing away the previous merge
> resolution information and redoing the merge from scratch. He really
> wanted a better solution, but the previous proposals didn't provide
> it.
OTOH, Buga has sketched the proposals, confirmed problem with my
original one (that Dscho predicted), then sketched the update I came up
with, and showed it does work in common cases as expected.
That said, I'm almost sure that for any method of rebasing and/or
merging of whatever, one motivated enough will be able to find corner
cases where the method fails, yet we do have both merges and rebases in
Git, and rebasing of merges falls to the same category. We need them.
Merges need to be properly rebased, not silently replaced with
(different) merges, unless user asks for re-merge explicitly. To me
Dscho (or anybody else) finding rough cases is an expected outcome, and
is not a convincing argument against the feature.
As for Dscho results specifically, I've got an impression that he never
needed rebasing of merges in the first place, and re-merging always
suited him just fine, so it'd be rather a surprise if rebasing of merges
suddenly started to work better for his needs and workflows once he has
implemented it.
That said, when better method(s) of rebasing of merges will be found,
I'm sure they'll be adopted, but for now I do believe we need something
reliable that has been checked to actually work for common cases, as
blind re-merging simply does not, and I still suspect the best choice
for the time being is Phillip's incremental method.
Overall, I'm still in desperate need for my precious merge-the-commits
be rebased, and not replaced with Git idea of how merge commit would
look if [current version of] 'git-merge' algorithm merged my branch in
[using Git current default settings]. It's my dream that Git finally
stops silently substituting a result of 'git-merge'
(just-a-helper-operation intended to simplify creation of merge commits)
for actual merge-the-commit that is part of my content.
Best regards,
-- Sergey Organov
^ permalink raw reply [relevance 5%]
* Re: The git newbie experience
@ 2006-05-15 8:39 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2006-05-15 8:39 UTC (permalink / raw)
To: Shawn Pearce, Tommi Virtanen; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
>> I'd rather do that with a diff file that can be used to do a
>> 3-way (see how rebase does it with --full-index diff with am -3).
>> No point creating and forgetting to remove a throw away branch
>> and getting more complaints.
>
> How is a quick stash different from a topic branch?
The original version of my message in response to TV looked like
this.
- Jack is a beginning user of git and does not (want to) understand
the index (right now).
- Jack works on branch X, say his HEAD points to X1. He has an edited,
uncommitted files with the names A, B and C.
- Jack wants to pull new changes made by others to his branch.
But "git merge" invoked from "git pull" says he needs to stash
away the local changes to do the merge.
- Jack stashes away what he has been working on and cleans up
his mess.
git checkout -b stash ;# risks error when "stash" exists
git commit -a -m 'Stashing WIP'
git checkout master ;# assuming that was where he was
- Jack then pulls. There are merge conflicts in files D, E, ..., Z.
- Jack resolves the merge conflicts and is ready to commit the resulting
merge. Note files A, B and C do not have his unfinished work.
There is no "if Jack does this or that" problem; he says "git
commit -a" because that is the only "commit" command he knows
about.
- Jack then reapplies what he stashed away, and keeps working.
git pull . --no-commit stash
git branch -D stash
You have to teach the new user to (1) name something, only to
immediately discard it when he returns to what he was in the
middle of, (2) remember to clean up the temporary thing once he
is done lest he forgets to clean it up (and common names like
"stash", "tmp" will be reused by accident causing grief next
time he needs to do another stash), and (3) use of --no-commit
pull.
On the other hand, "git stash/unstash" workflow would be quite
simple:
$ git stash >my.precious.state
... do whatever you want to deviate to
$ git unstash <my.precious.state
Merge resolve might be needed while unstashing, but
we are talking about pulling somebody else's work in "do
whatever" part, so that is something the user knows how to
perform anyway.
A quick and dirty stash implementation would go like this:
Stash is easy.
#!/bin/sh
# git stash
git diff --binary HEAD
git reset --hard
Unstash is a bit involved.
#!/bin/sh
# git unstash
. git-sh-setup
O_OBJECT=`cd "$GIT_OBJECT_DIRECTORY" && pwd`
O_DIR=`cd "$GIT_DIR" && pwd`
stash="$O_DIR/.stash$$"
rm -fr "$stash.*"
trap 'rm -rf $stash.*' 0
cat >"$stash.patch"
git-apply -z --index-info <"$stash.patch" >"$stash.list"
GIT_INDEX_FILE="$stash.index" \
GIT_OBJECT_DIRECTORY="$O_OBJECT" \
(
mkdir -p "$stash.tmp" &&
git-update-index -z --index-info <"$stash.list" &&
git-write-tree >"$stash.base" &&
cd "$stash.tmp" &&
git-apply --binary --index <"$stash.patch" &&
git-write-tree >"$stash.his"
)
his_tree=$(cat "$stash.his")
orig_tree=$(cat "$stash.base")
rm -fr "$stash.*"
git-merge-resolve $orig_tree -- HEAD $his_tree
This is essentially the core of "am -3" logic; if you are going
to use this for real, you would probably want to see if the
patch applies cleanly before falling back on the three-way
merge, though.
^ permalink raw reply [relevance 5%]
* Re: mergetool: what to do about deleting precious files?
2017-05-28 1:14 5% ` Junio C Hamano
@ 2017-05-28 10:24 5% ` Philip Oakley
2017-05-28 13:06 5% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Philip Oakley @ 2017-05-28 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> The git book [1] and a few blog posts [2] show how to preserve files
>> which
>> are in the current branch against changes that are on the branch being
>> merged in.
>>
>> e.g. (from [2])
>>
>> echo '<filemane> merge=ours' >> .gitattributes && # commit
>> git config --global merge.ours.driver true
>>
>> (test) $ git checkout demo
>> (demo) $ git merge -
>> # <filename> contents are not merged and the original retained.
>>
>>
>>
>> However what is not covered (at least in the documentation ) is the case
>> where the file to be ignored is not present on the current branch, but is
>> present on the branch to be merged in.
>
> Hmph. Per-path 'ours' and 'theirs' kick in only after we decide to
> perform the content level three-way merge. I wonder what would (not
> "should", but "would with the current code") happen, with the same
> attribute setting, if the file being merged were not changed by ours
> but modified by the side branch? I suspect that we'd take the change
> made by the side branch.
Here the 'ours' strategy is defined by the user's config file merge driver
list.
I'd understood it that once it was decided there was a merge to be performed
(the repective blob oid's in the repo/index are different) that the problem
of merging is then handed off to the declared merge driver.
>
>> Normal expectations would be that in such a case the new file from the
>> second parent branch would be added to the current branch.
>
The git-scm and blog posts suggest that the original is left in place at the
%P path, the merge driver run, and its return values used to decide if the
user has to go and resolve conflicts. By setting the driver to 'true', the
result is then said to be that the current 'blob' (i.e. file) is accepted
unchanged (in %P), so anything from the second parent blob was completely
ignored.
However if we have the addition of a new file, I can't tell from the docs
what should happen? Is this still a merge such that the merge driver is
called, or is the added file accepted without recourse to its .gitattributes
setting (surely that would be a bug).
Then assuming we have reached an external driver, and it wants to not add
that very file that was added in the second parent branch, what does the %P
path point to (/dev/null?) - in particular, shouldn't the docs say? (I've
not tested, and one test is not proof)
It maybe that the user wants a merge driver that says "If I ever see a
secret key or password, then remove the whole file", which (removing the
file from the merge) is a currently undocumented process (if even possible).
> So I do not think this is not limited to "new file". Anything that
> a tree-level three-way merge would resolve cleanly without having to
> consult the content-level three-way merge will complete without
> consulting the merge.ours.driver; per-file content-level three-way
> merge driver (which is what merge=<drivername> mechanism lets you
> specify via the attributes mechanism) is not something you would
> want to use for this kind of thing. It is purely for resolving the
> actual content-level conflicts.
>
That (that Git knows best) sounds just wrong. If the user has set a file
attribute strategy, why would we ignore it? We already have different
internal strategies anyway, so how do we even know that the potential merge
was conflict free if we have haven't checked its attribute type. Maybe I'm
missing something.
--
Philip
^ permalink raw reply [relevance 5%]
* [PATCH 4/4] Makefile: Don't pass $(ALL_CFLAGS) to the linker
@ 2010-06-23 19:48 5% Ramsay Jones
0 siblings, 0 replies; 200+ results
From: Ramsay Jones @ 2010-06-23 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
The msvc debug build (make MSVC=1 DEBUG=1) issues a warning
on every invocation of the linker:
LINK : warning LNK4044: unrecognized option '/Zi'; ignored
In order to suppress the warning, we refrain from passing the
$(ALL_CFLAGS) macro to the linker.
Note that, should it be necessary in the future, an option
intended for both the (front-end) compiler and the linker can
be included in both CFLAGS and LDFLAGS.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Makefile | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index b979fb7..2730199 100644
--- a/Makefile
+++ b/Makefile
@@ -1515,7 +1515,7 @@ git.s git.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"' \
'-DGIT_HTML_PATH="$(htmldir_SQ)"'
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
+ $(QUIET_LINK)$(CC) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
builtin/help.o: common-cmds.h
@@ -1810,17 +1810,17 @@ http-walker.s http-walker.o: EXTRA_CPPFLAGS = -DNO_EXPAT
endif
git-%$X: %.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
git-imap-send$X: imap-send.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL)
git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
$(REMOTE_CURL_ALIASES): $(REMOTE_CURL_PRIMARY)
@@ -1830,7 +1830,7 @@ $(REMOTE_CURL_ALIASES): $(REMOTE_CURL_PRIMARY)
cp $< $@
$(REMOTE_CURL_PRIMARY): remote-curl.o http.o http-walker.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
$(LIB_FILE): $(LIB_OBJS)
@@ -1934,7 +1934,7 @@ test-parse-options$X: parse-options.o
.PRECIOUS: $(TEST_OBJS)
test-%$X: test-%.o $(GITLIBS)
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
check-sha1:: test-sha1$X
./test-sha1.sh
--
1.7.1
^ permalink raw reply related [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
2018-11-26 9:30 5% ` Per Lundberg
@ 2018-11-26 10:28 5% ` Ævar Arnfjörð Bjarmason
2 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-11-26 10:28 UTC (permalink / raw)
To: Per Lundberg
Cc: brian m. carlson, git@vger.kernel.org, Steffen Jost,
Joshua Jensen, Junio C Hamano, Matthieu Moy, Clemens Buchacher,
Holger Hellmuth, Kevin Ballard,
Nguyễn Thái Ngọc Duy
On Mon, Nov 26 2018, Per Lundberg wrote:
> On 11/13/18 1:22 AM, brian m. carlson wrote:
>> This is going to totally hose automation. My last job had files which
>> might move from tracked to untracked (a file that had become generated),
>> and long-running CI and build systems would need to be able to check out
>> one status and switch to the other. Your proposed change will prevent
>> those systems from working, whereas they previously did.
>>
>> I agree that your proposal would have been a better design originally,
>> but breaking the way automated systems currently work is probably going
>> to be a dealbreaker.
>
> How about something like this:
>
> 1. Introduce a concept with "garbage" files, which git is "permitted to
> delete" without prompting.
>
> 2. Retain the current default, i.e. "ignored files are garbage" for now,
> making the new behavior _opt in_ to avoid breaking automated
> systems/existing scripts for anyone. Put the setting for this behind a
> new core.* config flag.
>
> 3. In the plan for version 3.0 (a new major version where some breakage
> can be tolerable, according to Semantic Versioning), change the default
> so that "only explicit garbage is garbage". Include very clear notices
> of this in the release notes. The config flag is retained, but its
> default changes from true->false or vice versa. People who dislike the
> new behavior can easily change back to the 2.x semantics.
>
> Would this be a reasonable compromise for everybody?
Possibly, but I think there's an earlier step zero there for anyone
interested in pursuing this (and currently I can't make time for it),
which is to submit a patch with tests and documentation showing exactly
the sort of scenarios where we clobber or don't clobber existing files.
As my https://public-inbox.org/git/87zhuf3gs0.fsf@evledraar.gmail.com/
shows we have tests for this, but they're not explicit, and some want to
test some unrelated thing.
I.e. to test the cases where we clobber foo.c because foo.c now
explicitly exists, or cases where dir/foo.c is clobbered because "dir"
is now a tracked text file etc., are those the only two cases? I vaguely
suspect that there were other interesting cases, but at this point the
information has been paged out of the working set of my wetware. The
thread at
https://public-inbox.org/git/87o9au39s7.fsf@evledraar.gmail.com/ has
some notes about this.
Then as noted in
https://public-inbox.org/git/87wopj3661.fsf@evledraar.gmail.com/ the
reason we have this behavior seems to be something that grew organically
from a semi-related bugfix.
So I don't think we're at a point where we're all dug into our trenches
and some people want X and others want Y and in the name of backwards
compatibility we're going to stay with X. It may turn out that we just
want to retain 10% of X, and can get 99% of the safety of Y by doing
that.
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
2018-11-28 3:58 5% ` Junio C Hamano
@ 2018-11-28 21:54 5% ` Ævar Arnfjörð Bjarmason
2018-12-01 6:21 5% ` Duy Nguyen
0 siblings, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-11-28 21:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Per Lundberg, brian m. carlson, git@vger.kernel.org, Steffen Jost,
Joshua Jensen, Matthieu Moy, Clemens Buchacher, Holger Hellmuth,
Kevin Ballard, Nguyễn Thái Ngọc Duy
On Wed, Nov 28 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> What do you think about some patch like that which retains the plumbing
>> behavior for things like read-tree, doesn't introduce "precious" or
>> "trashable", and just makes you specify "[checkout|merge|...] --force"
>> in cases where we'd have clobbering?
>
> Whether you like it or not, don't people's automation use tons of
> invocations of "git merge", "git checkout", etc.? You'd be breaking
> them by such a change.
I'm so sympathetic to this argument that I tried to convince you of
something like this around a year and a half ago:
https://public-inbox.org/git/CACBZZX59KXPOEjiUKtZLN6zjO_xpiWve7Xga6q-53J2LwvfZyw@mail.gmail.com/
:)
I was probing for what your current stance on this sort of thing is,
because discussions like this tend to get bogged down in the irrelevant
distraction of whether something is plumbing or porcelain, which almost
none of our users care about, and we've effectively stopped caring about
ourselves.
But we must have some viable way to repair warts in the tools, and
losing user data is a *big* wart.
I don't think something like the endgame you've described in
https://public-inbox.org/git/xmqqzhtwuhpc.fsf@gitster-ct.c.googlers.com/
is ever going to work. Novice git users (the vast majority) are not
going to diligently update both .gitignore and some .gitattribute
mechanism in lockstep. I'd bet most git users haven't read more than a
few paragraphs of our entire documentation at best.
So what's the way forward? I think ultimately we must move to something
where we effectively version the entire CLI UI similar to stable API
versions. I.e. for things like this that would break some things (or
Duy's new "split checkout") introduce them as flags first, then bundle
up all such flags and cut a major release "Git 3, 4, ...", and
eventually remove old functionality.
> Other than that, if we never had Git before and do not have to worry
> about existing users, I'd think it would be a lot closer to the ideal
> than today's system if "checkout <tree> foo.o" rejected overwriting
> "foo.o" that is not tracked in the current index but matches an ignore
> pattern, and required a "--force" option to overwrite it.
>
> A user, during a conflict resolution, may say "I want this 'git
> checkout foo/' to ignore conflicted paths in that directory, so I
> would give "--force" option to it, but now "--force" also implies
> that I am willing to clobber ignored paths, which means I cannot use
> it".
>
> I would think that a proper automation needs per-path hint from the
> user and/or the project, not just a single-size-fits-all --force
> option, and "unlike all the *.o ignored files that are expendable,
> this vendor-supplied-object.o is not" is one way to give such a
> per-path hint.
>
>> This would give scripts which relied on our stable plumbing consistent
>> behavior, while helping users who're using our main porcelain not to
>> lose data. I could then add a --force option to the likes of read-tree
>> (on by default), so you could get porcelain-like behavior with
>> --no-force.
>
> At that low level, I suspect that a single size fits all "--force"
> would work even less well.
Yeah I don't think the one-size-fits-all way out of this is a single
--force flag.
^ permalink raw reply [relevance 5%]
* [PATCH] Convert to use quiet option when available
@ 2009-04-23 1:46 5% Dan Loewenherz
0 siblings, 0 replies; 200+ results
From: Dan Loewenherz @ 2009-04-23 1:46 UTC (permalink / raw)
To: git, gitster
A minor fix that eliminates usage of "2>/dev/null" when --quiet or
-q has already been implemented.
Signed-off-by: Dan Loewenherz <daniel.loewenherz@yale.edu>
---
git-filter-branch.sh | 2 +-
git-merge-resolve.sh | 4 ++--
git-parse-remote.sh | 2 +-
git-pull.sh | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index b90d3df..37e044d 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -430,7 +430,7 @@ if [ "$filter_tag_name" ]; then
if [ "$type" = "tag" ]; then
# Dereference to a commit
sha1t="$sha1"
- sha1="$(git rev-parse "$sha1"^{commit} 2>/dev/null)" || continue
+ sha1="$(git rev-parse -q "$sha1"^{commit})" || continue
fi
[ -f "../map/$sha1" ] || continue
diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
index 93bcfc2..c9da747 100755
--- a/git-merge-resolve.sh
+++ b/git-merge-resolve.sh
@@ -37,10 +37,10 @@ then
exit 2
fi
-git update-index --refresh 2>/dev/null
+git update-index -q --refresh
git read-tree -u -m --aggressive $bases $head $remotes || exit 2
echo "Trying simple merge."
-if result_tree=$(git write-tree 2>/dev/null)
+if result_tree=$(git write-tree 2>/dev/null)
then
exit 0
else
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..a296719 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -2,7 +2,7 @@
# git-ls-remote could be called from outside a git managed repository;
# this would fail in that case and would issue an error message.
-GIT_DIR=$(git rev-parse --git-dir 2>/dev/null) || :;
+GIT_DIR=$(git rev-parse -q --git-dir) || :;
get_data_source () {
case "$1" in
diff --git a/git-pull.sh b/git-pull.sh
index 8c75027..3526153 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -147,7 +147,7 @@ then
echo >&2 "Warning: fetch updated the current branch head."
echo >&2 "Warning: fast forwarding your working tree from"
echo >&2 "Warning: commit $orig_head."
- git update-index --refresh 2>/dev/null
+ git update-index -q --refresh
git read-tree -u -m "$orig_head" "$curr_head" ||
die 'Cannot fast-forward your working tree.
After making sure that you saved anything precious from
--
1.6.3.rc1.34.g0be9b.dirty
^ permalink raw reply related [relevance 5%]
* [PATCH] Making CFLAGS compilant with GNU Coding Standards
@ 2005-08-06 5:36 5% Pavel Roskin
0 siblings, 0 replies; 200+ results
From: Pavel Roskin @ 2005-08-06 5:36 UTC (permalink / raw)
To: git
Hello!
Quoting GNU Coding Standards ("info standards"):
"If there are C compiler options that _must_ be used for proper
compilation of certain files, do not include them in `CFLAGS'. Users
expect to be able to specify `CFLAGS' freely themselves."
This patch renames COPTS to CFLAGS, because it's COPTS that was user
overridable. Also, -Wall is moved there because it's optional. What
was CFLAGS is now ALL_CFLAGS, which users should not override.
Defines are added to DEFINES. Since ALL_CFLAGS is recursively expanded,
it uses the final value of DEFINES.
Implicit rules are made explicit since the implicit rules use CFLAGS
rather than ALL_CFLAGS. I believe that serious projects should not rely
on implicit rules anyway. Percent rules are used because they are used
already and because they don't need the .SUFFIXES target.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -34,8 +34,8 @@
GIT_VERSION=0.99.3
-COPTS?=-g -O2
-CFLAGS+=$(COPTS) -Wall $(DEFINES)
+CFLAGS ?= -g -O2 -Wall
+ALL_CFLAGS = $(CFLAGS) $(DEFINES)
prefix=$(HOME)
bindir=$(prefix)/bin
@@ -125,7 +125,7 @@ ifndef NO_OPENSSL
LIB_OBJS += epoch.o
OPENSSL_LIBSSL=-lssl
else
- CFLAGS += '-DNO_OPENSSL'
+ DEFINES += '-DNO_OPENSSL'
MOZILLA_SHA1=1
OPENSSL_LIBSSL=
endif
@@ -146,8 +146,8 @@ endif
endif
endif
-CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
-CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
+DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
+DEFINES += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
@@ -156,9 +156,15 @@ CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRO
all: $(PROG)
+%.o: %.c
+ $(CC) -c $(ALL_CFLAGS) $<
+
+%.o: %.S
+ $(CC) -c $(ALL_CFLAGS) $<
+
.PRECIOUS: %.o
git-%: %.o $(LIB_FILE)
- $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+ $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
git-http-pull: pull.o
git-local-pull: pull.o
@@ -185,13 +191,13 @@ test: all
$(MAKE) -C t/ all
test-date: test-date.c date.o
- $(CC) $(CFLAGS) -o $@ test-date.c date.o
+ $(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o
test-delta: test-delta.c diff-delta.o patch-delta.o
- $(CC) $(CFLAGS) -o $@ $^
+ $(CC) $(ALL_CFLAGS) -o $@ $^
check:
- for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done
+ for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
--
Regards,
Pavel Roskin
^ permalink raw reply [relevance 5%]
* Re: Should notes handle replace commits?
@ 2016-01-11 16:50 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2016-01-11 16:50 UTC (permalink / raw)
To: Philip Oakley; +Cc: Mike Hommey, git
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Saturday, January 09, 2016 1:04 AM
>> Mike Hommey <mh@glandium.org> writes:
>>
>>> So while `cat-file commit A` gives you what `cat-file commit Z` would,
>>> `notes show A` doesn't give you what `notes show Z` would. And that's
>>> this "inconsistency" that bothers me.
>>
>> In any case, 'notes' being a way to add extra information to an
>> existing object means that with your original "replace" that tells
>> Git to keep A in the history (and give Z's contents when contents of
>> A was asked),
>> it is absolutely correct that notes for A is shown.
>
> This seems very wrong to me. Surely we have asked that _all_
> references to A be replaced by a reference to Z and thence onward to
> Z's contents.
You didn't ask any such thing.
I already said:
The true source of your confusion, I think, is that there is a
misunderstanding of what "replace A with Z" does.
It is NOT "whenever somebody refers to A, pretend as if it is
referring to Z". If that _were_ the case, then I'd agree that
"whenever somebody else asks notes attached to A, pretend as if
notes attached to Z were asked" might make sense, but that does not
match the reality.
but then didn't say what "the reality" is (because I already said it
elsewhere upthread).
What you asked is that whenever information in A is asked, a tweaked
version of the original information in A is returned. The tweaked
version happens to match what is in Z, but after the replacement,
the object Z does not directly get into the picture---as you can see
in the result of log (or rev-list) from C that shows "C B A Y X" (in
tip-to-root order), the end user does not even have to be aware of
Z's existence.
Let's think about the example of grafting "old" history that starts
at X, resurrected from archive since the history of the current
project has already started at A and leading to C in real-world
terms. A would be like Linus's v2.6.12-rc2 in the Linux kernel
project that does not have any parent. Then you rebuild the "old"
history from the archive that ends at the same v2.6.12-rc2, so your
X Y Z history also ends with v2.6.12-rc2. And you would "graft" it
behind the true history.
Commits A and Z would both have the same log message, record the
same tree, made by the same author and committer with same
timestamps.
Now, think which one of A and Z do you think people would want to
"survive" in the graft operation? Everybody has built (and will
continue to build) on the history that started at A whose tip is
currently at C.
If you have a way to tell Git "Earlier A was recorded as having NO
parent, but I wish we had recorded Y as its parent. So create a
fake reality where A's parent is Y.", then you can keep the
resulting world view consistent with the "recent-only" real history,
i.e. B's parent is still A. Some might even have notes on A, or
commits made since A may reference the commit object A by name in
its log, or another superproject may bind A as its subproject, but
because we are not changing the identity/name of A with Z, all of
these "external" references survive the grafting/replacing.
Perhaps it would help if you stop thinking that you are somehow
losing "Z" and "Z" is somehow precious. It is not, at least in the
"history grafting" context, at all precious.
When you have the true history starting from v2.6.12-rc2 (that is "A
B C"), the thing you REALLY want to do is to resurrect history that
ends at one commit before v2.6.12-rc2 (that is "Y" in the example),
and somehow tweak "A" so that its parent is "Y". And the way you
tweak "A" to make that happen is to replace its contents with the
contents of a commit that records all the same information as "A"
except that it has a parent that is "Y". We could do "cat-file
commit A" piped to sed to add a "parent Y" line to it and then
"hash-object" to come up with such a replacement commit, and replace
A with it, but "Z" happens to be such a commit already, so that is
why replacing A with Z would graft Y just behind A. The resulting
history would show Y as the parent of A and Z won't even be in the
consciousness of the end users. The "old history resurrection"
project does not even have to create "Z" in the first place.
If the contents of "Z" is different from contents of "A" in some
other way, other than their set of parents, or if "Z" has other
external references that are precious (e.g. a note may refer to it,
or a superproject may bind Z to its tree), then either replacing A
with Z or replacing Z with A would not be a good way to connect the
two histories. As you would want to keep both, and the "external"
references, such as notes and submodule gitlink bindings, want to
keep refering to both.
In such a case, the best you can do is to tweak A to have Z (instead
of Y) as its fake parent, to make the resulting fake history read
like "C B A Z Y X" (in tip-to-root order), having two copies of
v2.6.12-rc2. That way you would be able to see both notes for A and
Z, and can tell which note was attached to the true history and
which note was attached to the history resurrected from the archive.
^ permalink raw reply [relevance 5%]
* [PATCH v4 0/2] gc: introduce `gc.recentObjectsHook`
2023-06-07 22:58 5% ` [PATCH v5 0/2] gc: introduce `gc.recentObjectsHook` Taylor Blau
@ 2023-05-16 0:23 5% ` Taylor Blau
1 sibling, 1 reply; 200+ results
From: Taylor Blau @ 2023-05-16 0:23 UTC (permalink / raw)
To: git; +Cc: Derrick Stolee, Jeff King, Junio C Hamano, Chris Torek
Here is another reworked version of the patch which introduced a new
configuration `gc.extraCruftTips` to keep additional objects when
pruning which might have otherwise aged out of the repository.
Notable changes since last time include:
- updating the name of this configuration to "gc.recentObjectsHook",
- significantly reworking the substantive patch's message
- improved test coverage to cover more cases of loose object pruning,
as well as `git prune`'s interaction with `gc.recentObjectsHook`.
(Again, since we're expecting -rc0, I don't expect a ton of movement on
this series before 2.41 is shipped, but I figured I'd share it out
anyways to get it off of my laptop).
Thanks in advance for your review.
Taylor Blau (2):
reachable.c: extract `obj_is_recent()`
gc: introduce `gc.recentObjectsHook`
Documentation/config/gc.txt | 13 ++
reachable.c | 85 ++++++++++++-
t/t5304-prune.sh | 14 +++
t/t5329-pack-objects-cruft.sh | 171 +++++++++++++++++++++++++++
t/t7701-repack-unpack-unreachable.sh | 31 +++++
5 files changed, 311 insertions(+), 3 deletions(-)
Range-diff against v3:
1: f5f3b0f334 = 1: 9c1b59c8cf reachable.c: extract `obj_is_recent()`
2: 2ce8a79fa4 ! 2: 18e50d2517 builtin/pack-objects.c: introduce `pack.recentObjectsHook`
@@ Metadata
Author: Taylor Blau <me@ttaylorr.com>
## Commit message ##
- builtin/pack-objects.c: introduce `pack.recentObjectsHook`
+ gc: introduce `gc.recentObjectsHook`
This patch introduces a new multi-valued configuration option,
- `pack.recentObjectsHook` as a means to mark certain objects as recent,
- regardless of their age.
+ `gc.recentObjectsHook` as a means to mark certain objects as recent (and
+ thus exempt from garbage collection), regardless of their age.
- Depending on whether or not we are generating a cruft pack, this allows
- the caller to do one of two things:
+ When performing a garbage collection operation on a repository with
+ unreachable objects, Git makes its decision on what to do with those
+ object(s) bed on how recent the objects are or not. Generally speaking,
+ unreachable-but-recent objects stay in the repository, and older objects
+ are discarded.
- - If generating a cruft pack, the caller is able to retain additional
- objects via the cruft pack, even if they would have otherwise been
- pruned due to their age.
+ However, we have no convenient way to keep certain precious, unreachable
+ objects around in the repository, even if they have aged out and would
+ be pruned. Our options today consist of:
- - If not generating a cruft pack, the caller is likewise able to
- retain additional objects as loose.
+ - Point references at the reachability tips of any objects you
+ consider precious, which may be undesirable or infeasible.
- There is currently no option to be able to keep around certain objects
- that have otherwise aged out of the grace period. The only way to retain
- those objects is:
-
- - to point a reference at them, which may be undesirable or
- infeasible,
-
- - to track them via the reflog, which may be undesirable since the
+ - Track them via the reflog, which may be undesirable since the
reflog's lifetime is limited to that of the reference it's tracking
(and callers may want to keep those unreachable objects around for
- longer)
+ longer).
- - to extend the grace period, which may keep around other objects that
- the caller *does* want to discard,
+ - Extend the grace period, which may keep around other objects that
+ the caller *does* want to discard.
- - or, to force the caller to construct the pack of objects they want
+ - Manually modify the mtimes of objects you want to keep. If those
+ objects are already loose, this is easy enough to do (you can just
+ enumerate and `touch -m` each one).
+
+ But if they are packed, you will either end up modifying the mtimes
+ of *all* objects in that pack, or be forced to write out a loose
+ copy of that object, both of which may be undesirable. Even worse,
+ if they are in a cruft pack, that requires modifying its `*.mtimes`
+ file by hand, since there is no exposed plumbing for this.
+
+ - Force the caller to construct the pack of objects they want
to keep themselves, and then mark the pack as kept by adding a
- ".keep" file.
+ ".keep" file. This works, but is burdensome for the caller, and
+ having extra packs is awkward as you roll forward your cruft pack.
- This patch introduces a new configuration, `pack.recentObjectsHook`
- which allows the caller to specify a program (or set of programs) whose
- output is treated as a set of objects to treat as recent, regardless of
- their true age.
+ This patch introduces a new option to the above list via the
+ `gc.recentObjectsHook` configuration, which allows the caller to
+ specify a program (or set of programs) whose output is treated as a set
+ of objects to treat as recent, regardless of their true age.
- The implementation is straightforward. In either case (cruft packs or
- not), Git enumerates recent objects via
- `add_unseen_recent_objects_to_traversal()`. That enumerates loose and
+ The implementation is straightforward. Git enumerates recent objects via
+ `add_unseen_recent_objects_to_traversal()`, which enumerates loose and
packed objects, and eventually calls add_recent_object() on any objects
for which `want_recent_object()`'s conditions are met.
This patch modifies the recency condition from simply "is the mtime of
this object more recent than the cutoff?" to "[...] or, is this object
- mentioned by at least one `pack.recentObjectsHook`?".
+ mentioned by at least one `gc.recentObjectsHook`?".
- We then add those as tips to another reachability traversal (along with
- any recent objects, if pruning), marking every object along the way
- (either adding it to the cruft pack, or writing it out as a loose
- object).
+ Depending on whether or not we are generating a cruft pack, this allows
+ the caller to do one of two things:
+
+ - If generating a cruft pack, the caller is able to retain additional
+ objects via the cruft pack, even if they would have otherwise been
+ pruned due to their age.
+
+ - If not generating a cruft pack, the caller is likewise able to
+ retain additional objects as loose.
A potential alternative here is to introduce a new mode to alter the
contents of the reachable pack instead of the cruft one. One could
@@ Commit message
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
- ## Documentation/config/pack.txt ##
-@@ Documentation/config/pack.txt: pack.deltaCacheLimit::
- result once the best match for all objects is found.
- Defaults to 1000. Maximum value is 65535.
+ ## Documentation/config/gc.txt ##
+@@ Documentation/config/gc.txt: or rebase occurring. Since these changes are not part of the current
+ project most users will want to expire them sooner, which is why the
+ default is more aggressive than `gc.reflogExpire`.
-+pack.recentObjectsHook::
++gc.recentObjectsHook::
+ When considering the recency of an object (e.g., when generating
+ a cruft pack or storing unreachable objects as loose), use the
+ shell to execute the specified command(s). Interpret their
@@ Documentation/config/pack.txt: pack.deltaCacheLimit::
+operation (either generating a cruft pack or unpacking unreachable
+objects) will be halted.
+
- pack.threads::
- Specifies the number of threads to spawn when searching for best
- delta matches. This requires that linkgit:git-pack-objects[1]
-
- ## builtin/pack-objects.c ##
-@@
- #include "pack-mtimes.h"
- #include "parse-options.h"
- #include "wrapper.h"
-+#include "run-command.h"
-
- /*
- * Objects we are going to pack are collected in the `to_pack` structure.
+ gc.rerereResolved::
+ Records of conflicted merge you resolved earlier are
+ kept for this many days when 'git rerere gc' is run.
## reachable.c ##
@@
@@ reachable.c: struct recent_data {
+ int extra_recent_oids_loaded;
};
-+static int run_one_pack_recent_objects_hook(struct oidset *set,
++static int run_one_gc_recent_objects_hook(struct oidset *set,
+ const char *args)
+{
+ struct child_process cmd = CHILD_PROCESS_INIT;
@@ reachable.c: struct recent_data {
+
+ if (parse_oid_hex(buf.buf, &oid, &rest) || *rest) {
+ ret = error(_("invalid extra cruft tip: '%s'"), buf.buf);
-+ goto done;
++ break;
+ }
+
+ oidset_insert(set, &oid);
+ }
+
-+ ret = finish_command(&cmd);
++ fclose(out);
++ ret |= finish_command(&cmd);
+
-+done:
-+ if (out)
-+ fclose(out);
+ strbuf_release(&buf);
-+ child_process_clear(&cmd);
-+
+ return ret;
+}
+
-+static void load_pack_recent_objects(struct recent_data *data)
++static void load_gc_recent_objects(struct recent_data *data)
+{
+ const struct string_list *programs;
+ int ret = 0;
@@ reachable.c: struct recent_data {
+
+ data->extra_recent_oids_loaded = 1;
+
-+ if (git_config_get_string_multi("pack.recentobjectshook", &programs))
++ if (git_config_get_string_multi("gc.recentobjectshook", &programs))
+ return;
+
+ for (i = 0; i < programs->nr; i++) {
-+ ret = run_one_pack_recent_objects_hook(&data->extra_recent_oids,
++ ret = run_one_gc_recent_objects_hook(&data->extra_recent_oids,
+ programs->items[i].string);
+ if (ret)
-+ break;
++ die(_("unable to enumerate additional cruft tips"));
+ }
-+
-+ if (ret)
-+ die(_("unable to enumerate additional cruft tips"));
+}
+
static int obj_is_recent(const struct object_id *oid, timestamp_t mtime,
@@ reachable.c: struct recent_data {
+ return 1;
+
+ if (!data->extra_recent_oids_loaded)
-+ load_pack_recent_objects(data);
++ load_gc_recent_objects(data);
+ return oidset_contains(&data->extra_recent_oids, oid);
}
static void add_recent_object(const struct object_id *oid,
-@@ reachable.c: static int want_recent_object(struct recent_data *data,
- const struct object_id *oid)
- {
- if (data->ignore_in_core_kept_packs &&
-- has_object_kept_pack(oid, IN_CORE_KEEP_PACKS))
-+ has_object_kept_pack(oid, IN_CORE_KEEP_PACKS)) {
-+ if (!data->extra_recent_oids_loaded)
-+ load_pack_recent_objects(data);
-+ if (oidset_contains(&data->extra_recent_oids, oid))
-+ return 1;
-+
- return 0;
-+ }
- return 1;
- }
-
@@ reachable.c: int add_unseen_recent_objects_to_traversal(struct rev_info *revs,
data.cb = cb;
data.ignore_in_core_kept_packs = ignore_in_core_kept_packs;
@@ reachable.c: int add_unseen_recent_objects_to_traversal(struct rev_info *revs,
static int mark_object_seen(const struct object_id *oid,
+ ## t/t5304-prune.sh ##
+@@ t/t5304-prune.sh: test_expect_success 'old reachable-from-recent retained with bitmaps' '
+ test_must_fail git cat-file -e $to_drop
+ '
+
++test_expect_success 'gc.recentObjectsHook' '
++ add_blob &&
++ test-tool chmtime =-86500 $BLOB_FILE &&
++
++ write_script precious-objects <<-EOF &&
++ echo $BLOB
++ EOF
++ test_config gc.recentObjectsHook ./precious-objects &&
++
++ git prune --expire=now &&
++
++ git cat-file -p $BLOB
++'
++
+ test_done
+
## t/t5329-pack-objects-cruft.sh ##
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend via loose' '
)
'
-+test_expect_success 'additional cruft tips may be specified via pack.extraCruftTips' '
++test_expect_success 'gc.recentObjectsHook' '
+ git init repo &&
+ test_when_finished "rm -fr repo" &&
+ (
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ write_script extra-tips <<-EOF &&
+ echo $cruft_old
+ EOF
-+ git config pack.recentObjectsHook ./extra-tips &&
++ git config gc.recentObjectsHook ./extra-tips &&
+
+ git repack --cruft --cruft-expiration=now -d &&
+
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ test_cmp cruft.expect cruft.actual &&
+
+ # Ensure that the "old" objects are removed after
-+ # dropping the pack.extraCruftTips hook.
-+ git config --unset pack.recentObjectsHook &&
++ # dropping the gc.recentObjectsHook hook.
++ git config --unset gc.recentObjectsHook &&
+ git repack --cruft --cruft-expiration=now -d &&
+
+ mtimes="$(ls .git/objects/pack/pack-*.mtimes)" &&
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ )
+'
+
-+test_expect_success 'multi-valued pack.extraCruftTips' '
++test_expect_success 'multi-valued gc.recentObjectsHook' '
+ git init repo &&
+ test_when_finished "rm -fr repo" &&
+ (
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+
+ # ensure that each extra cruft tip is saved by its
+ # respective hook
-+ git config --add pack.recentObjectsHook ./extra-tips.a &&
-+ git config --add pack.recentObjectsHook ./extra-tips.b &&
++ git config --add gc.recentObjectsHook ./extra-tips.a &&
++ git config --add gc.recentObjectsHook ./extra-tips.b &&
+ git repack --cruft --cruft-expiration=now -d &&
+
+ mtimes="$(ls .git/objects/pack/pack-*.mtimes)" &&
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ test_cmp cruft.expect cruft.actual &&
+
+ # ensure that a dirty exit halts cruft pack generation
-+ git config --add pack.recentObjectsHook ./extra-tips.c &&
++ git config --add gc.recentObjectsHook ./extra-tips.c &&
+ test_must_fail git repack --cruft --cruft-expiration=now -d 2>err &&
+ grep "unable to enumerate additional cruft tips" err &&
+
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ )
+'
+
-+test_expect_success 'additional cruft blobs via pack.extraCruftTips' '
++test_expect_success 'additional cruft blobs via gc.recentObjectsHook' '
+ git init repo &&
+ test_when_finished "rm -fr repo" &&
+ (
@@ t/t5329-pack-objects-cruft.sh: test_expect_success 'cruft objects are freshend v
+ write_script extra-tips <<-EOF &&
+ echo $blob
+ EOF
-+ git config pack.recentObjectsHook ./extra-tips &&
++ git config gc.recentObjectsHook ./extra-tips &&
+
+ git repack --cruft --cruft-expiration=now -d &&
+
@@ t/t7701-repack-unpack-unreachable.sh: test_expect_success 'do not bother looseni
test_must_fail git cat-file -p $obj2
'
-+test_expect_success 'extra recent tips are kept regardless of age' '
++test_expect_success 'gc.recentObjectsHook' '
+ obj1=$(echo one | git hash-object -w --stdin) &&
+ obj2=$(echo two | git hash-object -w --stdin) &&
++ obj3=$(echo three | git hash-object -w --stdin) &&
+ pack1=$(echo $obj1 | git pack-objects .git/objects/pack/pack) &&
+ pack2=$(echo $obj2 | git pack-objects .git/objects/pack/pack) &&
++ pack3=$(echo $obj3 | git pack-objects .git/objects/pack/pack) &&
+ git prune-packed &&
+
+ git cat-file -p $obj1 &&
+ git cat-file -p $obj2 &&
++ git cat-file -p $obj3 &&
+
-+ write_script extra-tips <<-EOF &&
-+ echo $obj2
++ git tag -a -m tag obj2-tag $obj2 &&
++ obj2_tag="$(git rev-parse obj2-tag)" &&
++
++ write_script precious-objects <<-EOF &&
++ echo $obj2_tag
+ EOF
-+ git config pack.recentObjectsHook ./extra-tips &&
++ git config gc.recentObjectsHook ./precious-objects &&
+
+ test-tool chmtime =-86400 .git/objects/pack/pack-$pack2.pack &&
++ test-tool chmtime =-86400 .git/objects/pack/pack-$pack3.pack &&
+ git repack -A -d --unpack-unreachable=1.hour.ago &&
+
+ git cat-file -p $obj1 &&
-+ git cat-file -p $obj2
++ git cat-file -p $obj2 &&
++ git cat-file -p $obj2_tag &&
++ test_must_fail git cat-file -p $obj3
+'
+
test_expect_success 'keep packed objects found only in index' '
--
2.40.1.558.g18e50d2517
^ permalink raw reply [relevance 5%]
* Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory
@ 2024-01-23 5:40 5% ` Raúl Núñez de Arenas Coronado
0 siblings, 1 reply; 200+ results
From: Raúl Núñez de Arenas Coronado @ 2024-01-23 5:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
Hi Jeff, and thanks for your reply :)
El lun, 22 ene 2024 a las 22:34, Jeff King (<peff@peff.net>) escribió:
> For example, I get:
>
> [setup]
> $ git init
> $ mkdir subdir
> $ echo '*' >subdir/.gitignore
> $ git add -f subdir/.gitignore && git commit -m "add gitignore"
> $ touch subdir/file file
>
> [no exclusions]
> $ git ls-files -o
> file
> subdir/file
>
> [use .gitignore]
> $ git ls-files --exclude-per-directory=.gitignore -o
> file
>
> [using standard excludes]
> $ git ls-files --exclude-standard -o
> file
>
> Do you get different results from that toy repo? If not, then what is
> different about your main repo? Do you perhaps have a stray "*" match
> somewhere in .git/info/exclude, etc? Or are you still providing
> --exclude-from in addition to --exclude-standard?
The difference lies in how I deal in my computer with ignored files. I
have some files in all my repos which have to be ignored always, so I
have that pattern in my core.excludes file. BUT those files have to be
backed up on my system, just in case my local copy of the repo is lost
for some reason, as they are files I need for development in my
personal machine.
If I use --exclude-standard, no matter if those files are being
ignored by core.excludes OR .git/info/exclude, they won't appear in
that 'list other files' command output.
So, my previous idea was ignore ONLY those files ignored by the
repository .gitignore file. That way, the other files that go in my
core.excludes or .git/info/exclude will be listed and backed up. The
problem here is that some of the repository gitignored files (files
related to building, testing, etc.) have their own .gitignore file
containing '*", but they are NOT present in the repo .gitignore. This
is a common practice for Python virtual environments, for example.
Summing up: or I end up backing up those directories that have their
own .gitignore file (not the end of the world) or I use a different
solution to decide which files are ignored but "precious" (I love that
concept, see Junio C Hamano message for that) OR I add those
directories to the .gitignore present in the repo. This last idea I
don't like very much, as they are particular to my system, not the
repo, for example, *I* may decide to use ESLint and node_modules for
some particular web page I'm writing, but the related configuration
should not go into the repository and should not be ignored in
.gitignore, but in .git/info/exclude. I won't backup node_modules, of
course, it is going to be recreated, but I may want to back up
packages.json and .eslintrc. And both of those files will go into
.git/info/exclude, so if I use --exclude-standard, they won't be
backed up.
Since as both Junio and you correctly pointed, this is in fact the
expected, I'll try to find a different solution while the "precious"
concept is finally implemented. I have a couple of ideas, like using a
.giprecious file which my backup script can process easily, containing
the untracked files to back-up.
Thanks for the toy repo, helped me test the differences with my setup!
--
Raúl Núñez de Arenas Coronado
.
^ permalink raw reply [relevance 5%]
* [PATCH 08/14] pull: fast-forward working tree if head is updated
@ 2015-05-18 15:06 5% ` Paul Tan
0 siblings, 0 replies; 200+ results
From: Paul Tan @ 2015-05-18 15:06 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Johannes Schindelin, Stephen Robin, Paul Tan
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
---
builtin/pull.c | 30 ++++++++++++++++++++++++++++++
t/t5520-pull.sh | 4 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/builtin/pull.c b/builtin/pull.c
index 9b06dfa..3b7029f 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -468,6 +468,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
{
const char *repo, **refspecs;
struct sha1_array merge_heads = SHA1_ARRAY_INIT;
+ unsigned char orig_head[GIT_SHA1_RAWSZ], curr_head[GIT_SHA1_RAWSZ];
argc = parse_options(argc, argv, prefix, pull_options, pull_usage, 0);
parse_repo_refspecs(argc, argv, &repo, &refspecs);
@@ -483,12 +484,41 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
if (!opt_ff)
opt_ff = xstrdup_or_null(config_get_ff());
+ if (get_sha1("HEAD", orig_head))
+ hashclr(orig_head);
+
if (run_fetch(repo, refspecs))
return 1;
if (opt_dry_run)
return 0;
+ if (get_sha1("HEAD", curr_head))
+ hashclr(curr_head);
+
+ if (!is_null_sha1(orig_head) && !is_null_sha1(curr_head) &&
+ hashcmp(orig_head, curr_head)) {
+ /*
+ * The fetch involved updating the current branch.
+ *
+ * The working tree and the index file are still based on
+ * orig_head commit, but we are merging into curr_head.
+ * Update the working tree to match curr_head.
+ */
+
+ warning(_("fetch updated the current branch head.\n"
+ "fast-forwarding your working tree from\n"
+ "commit %s."), sha1_to_hex(orig_head));
+
+ if (checkout_fast_forward(orig_head, curr_head, 0))
+ die(_("Cannot fast-forward your working tree.\n"
+ "After making sure that you saved anything precious from\n"
+ "$ git diff %s\n"
+ "output, run\n"
+ "$ git reset --hard\n"
+ "to recover."), sha1_to_hex(orig_head));
+ }
+
get_merge_heads(&merge_heads);
if (!merge_heads.nr)
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 4c52175..3645a59 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -191,7 +191,7 @@ test_expect_success 'fail if the index has unresolved entries' '
test_cmp expected file
'
-test_expect_failure 'fast-forwards working tree if branch head is updated' '
+test_expect_success 'fast-forwards working tree if branch head is updated' '
git checkout -b third second^ &&
test_when_finished "git checkout -f copy && git branch -D third" &&
test "$(cat file)" = file &&
@@ -201,7 +201,7 @@ test_expect_failure 'fast-forwards working tree if branch head is updated' '
test "$(git rev-parse third)" = "$(git rev-parse second)"
'
-test_expect_failure 'fast-forward fails with conflicting work tree' '
+test_expect_success 'fast-forward fails with conflicting work tree' '
git checkout -b third second^ &&
test_when_finished "git checkout -f copy && git branch -D third" &&
test "$(cat file)" = file &&
--
2.1.4
^ permalink raw reply related [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
@ 2018-11-11 16:55 5% ` Ævar Arnfjörð Bjarmason
1 sibling, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-11-11 16:55 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, jost, Joshua Jensen, per.lundberg,
Junio C Hamano, git, Clemens Buchacher, Holger Hellmuth (IKS),
Kevin Ballard
On Sun, Nov 11 2018, Duy Nguyen wrote:
> On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> The users who need protection against git deleting their files the most
>> are exactly the sort of users who aren't expert-level enough to
>> understand the nuances of how the semantics of .gitignore and "precious"
>> are going to interact before git eats their data.
>>
>> This is pretty apparent from the bug reports we're getting about
>> this. None of them are:
>>
>> "Hey, I 100% understood .gitignore semantics including this one part
>> of the docs where you say you'll do this, but just forgot one day
>> and deleted my work. Can we get some more safety?"
>>
>> But rather (with some hyperbole for effect):
>>
>> "ZOMG git deleted my file! Is this a bug??"
>>
>> So I think we should have the inverse of this "precious"
>> attribute". Just a change to the docs to say that .gitignore doesn't
>> imply these eager deletion semantics on tree unpacking anymore, and if
>> users want it back they can define a "garbage" attribute
>> (s/precious/garbage/).
>>
>> That will lose no data, and in the very rare cases where a checkout of
>> tracked files would overwrite an ignored pattern, we can just error out
>> (as we do with the "Ok to overwrite" branch removed) and tell the user
>> to delete the files to proceed.
>
> There's also the other side of the coin. If this refuse to overwrite
> triggers too often, it can become an annoyance. So far I've seen two
> reports of accident overwriting which make me think turning precious
> to trashable may be too extreme. Plus ignored files are trashable by
> default (or at least by design so far), adding trashable attribute
> changes how we handle ignored files quite significantly.
Yeah I'm not trying to make the argument that we should just go with
these user bug reports, clearly that's just going to give us selection
bias and we could continue to flip between the two behaviors with that
approach. Just that an advanced opt-in feature to prevent dataloss will
not prevent it in practice.
Is taking my patch the right thing? I don't know. I'm leaning in that
direction, but more making a devil's advocate argument to see if anyone
finds good cases that'll demonstrate how it's bad. I haven't read/seen
them so far, and the test suite didn't have any.
I did go through the list archives as Junio suggested in
https://public-inbox.org/git/7viq39avay.fsf@alter.siamese.dyndns.org/
and found these two:
https://public-inbox.org/git/?q=d%3A20070301..20070331+verify_absent
It seems to me that the reason we ended up with this behavior is a bug
report from Shawn that was describing a similar but not quite the same
problem:
"[...]a bug in read-tree -m that prevents him from switching
branches when the type of a path changes between a directory and a
file.[...]"
That's not the same as when a now-tracked file clobbers a .gitignored
file. As far as I can tell (but may not have read carefully enough) that
wasn't a problem anyone reported, but was changed while fixing another
bug in c81935348b ("Fix switching to a branch with D/F when current
branch has file D.", 2007-03-15).
^ permalink raw reply [relevance 5%]
* Re: mergetool: what to do about deleting precious files?
@ 2017-05-30 0:52 5% ` Junio C Hamano
2017-05-30 23:04 5% ` Philip Oakley
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2017-05-30 0:52 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
"Philip Oakley" <philipoakley@iee.org> writes:
> If I now understand correctly, the merge process flow is:
>
> * canonicalise content (eol, smudge-clean, $id, renormalise, etc)
> * diff the content (internal, or GIT_EXTERNAL_DIFF)
> * apply the diff
> * if conflicts, only then use merge-driver/tool
>
> Would that be a correct interpretation?
Not quite. There are a lot more going on before any of those steps:
* Find the common ancestor commit (which could be many).
* Walk the three trees (the common ancestor's, ours and theirs) in
parallel, noticing what happened to each path. Depending on what
happened to the path in each branch, the merge may or may not
"conflict" (e.g. when both sides added exactly the same contents
to the same path, they are not counted as conflicting. when we
removed while they modified, they show as conflicting).
* For paths that are conflicting, feed the canonicalized content of
the versions from common, ours and theirs to the file-level merge
driver. The builtin file-level merge driver takes two xdiff (one
between ancestor and ours, the other between ancestore and
theirs) and reconciles them to produce the result. But that is
irrelevant in the context of "custom merge driver"; the builtin
one is skipped altogether and the custom contents merge driver
the user specified via the attributes is used instead.
Notice that the second step above has no customization knobs. Any
path the second step deems not to conflict is "merged cleanly"
without even triggering the "oops, ours and theirs did conflicting
changes, to the content; let's see how the final content should look
like" (aka the third step). This is *not* because "Git knows the
best"; it is merely that nobody felt the need for a mechanism to
allow customizing the second step.
And that is why I said you need a new customization mechanism if you
want to affect the outcome of the scenario that started this thread.
^ permalink raw reply [relevance 5%]
* [PATCH 2/4] Encode the manpage section in the file name
@ 2006-03-10 14:43 5% ` Jonas Fonseca
2006-03-10 14:44 5% ` [PATCH 3/4] Generate PDF documents using docbook2pdf Jonas Fonseca
1 sibling, 0 replies; 200+ results
From: Jonas Fonseca @ 2006-03-10 14:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
This makes it easier to handle other document types.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 39 +++++++++++++++++++++++++++------------
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 661c259..00e9276 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -3,13 +3,13 @@ CG_SRC=$(filter-out $(CG_IGNORE), $(wild
PACKAGE=cogito
-MAN1_TXT=$(patsubst ../cg%,cg%.txt,$(CG_SRC))
-MAN7_TXT=$(PACKAGE).txt
+MAN1_TXT=$(patsubst ../cg%,cg%.1.txt,$(CG_SRC))
+MAN7_TXT=$(PACKAGE).7.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) introduction.html
-DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
-DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+DOC_MAN1=$(patsubst %.txt,%,$(MAN1_TXT))
+DOC_MAN7=$(patsubst %.txt,%,$(MAN7_TXT))
prefix=$(HOME)
bin=$(prefix)/bin
@@ -56,28 +56,43 @@ install-html: html
$(INSTALL) $(DOC_HTML) $(DESTDIR)/$(htmldir)
clean:
- rm -f *.xml *.html *.1 *.7 cg*.txt $(PACKAGE).txt
+ rm -f *.xml *.html *.1 *.7 cg*.[17].txt $(PACKAGE).7.txt
.PRECIOUS: cg%.txt
introduction.html: ../README
asciidoc -b xhtml11 -d article -f asciidoc.conf -o $@ $<
-%.html : %.txt
+%.1.html : %.1.txt
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
-%.1 %.7 : %.xml
- xmlto man $<
+%.7.html : %.7.txt
+ asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
-%.xml : %.txt
+%.html : %.txt
+ asciidoc -b xhtml11 -d article -f asciidoc.conf -o $@ $<
+
+%.1.xml : %.1.txt
asciidoc -b docbook -d manpage -f asciidoc.conf $<
-$(PACKAGE).txt : make-$(PACKAGE)-asciidoc
+%.7.xml : %.7.txt
+ asciidoc -b docbook -d manpage -f asciidoc.conf $<
+
+%.xml : %.txt
+ asciidoc -b docbook -d article -f asciidoc.conf $<
+
+%.1 : %.1.xml
+ xmlto man $<
+
+%.7 : %.7.xml
+ xmlto man $<
+
+$(PACKAGE).7.txt : make-$(PACKAGE)-asciidoc
./make-$(PACKAGE)-asciidoc > $@
# It seems that cg%.txt won't match this so use an explicit rule
-cg.txt : ../cg make-cg-asciidoc
+cg.1.txt : ../cg make-cg-asciidoc
CGPACKAGE=$(PACKAGE) ./make-cg-asciidoc $< > $@
-cg-%.txt : ../cg-% make-cg-asciidoc
+cg-%.1.txt : ../cg-% make-cg-asciidoc
CGPACKAGE=$(PACKAGE) ./make-cg-asciidoc $< > $@
--
Jonas Fonseca
^ permalink raw reply related [relevance 5%]
* Re: [PATCH v4 2/2] gc: introduce `gc.recentObjectsHook`
@ 2023-06-07 22:56 5% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2023-06-07 22:56 UTC (permalink / raw)
To: Glen Choo
Cc: git, Derrick Stolee, Jeff King, Junio C Hamano, Chris Torek, me,
martinvonz
Hi Glen,
Apologies for my delayed response. Now that we are on the other side of
2.41 I think that it's the right time to pick this back up again.
On Wed, May 24, 2023 at 04:21:34PM -0700, Glen Choo wrote:
> Hi Taylor! It was great seeing you at Review Club today :)
It was fun :-).
> It would be useful to flesh out why keeping these extra refs are
> either "undesirable" or "infeasible". Presumably, you already have
> some idea of why this is the case for the GitHub 'audit log'.
Yes, thanks for suggesting it. I think the gap in my explanation is
"[...] if there are many such objects". Hopefully that clarifies it.
> Another potential use case I can think of is client-side third party Git
> tools that implement custom workflows on top of a Git repo, e.g.
> git-branchless (https://github.com/arxanas/git-branchless) and jj
> (https://github.com/martinvonz/jj/, btw I contribute a little to jj
> too).
I thought that this was an interesting part of the discussion. I hadn't
thought of it when writing up these patches, but I think that it could
be potentially useful for those tools if they want to keep around some
precious set of metadata objects without having to point refs at them.
It also introduces a little bit of a higher barrier between the tool and
user to destroy those objects. Without pinning them with this hook, all
a user has to do to remove them is drop the reference(s) which points at
them, and then GC. Now they'd have to modify the hook, etc.
> > +gc.recentObjectsHook::
>
> I have a small preference to use "command" instead of "hook" to avoid
> confusion with Git hooks (I've already observed some of this confusion
> in off-list conversations). There's some precedent for "hook" in
> `uploadpack.packObjectsHook`, but that's a one-off (and it used to
> confuse me a lot too :P).
Unless you feel strongly, let's leave it as-is. "gc.recentObjectsHook"
is the third iteration of this name, and I'd like to avoid spending much
more time on naming if we can help it.
> > + When considering the recency of an object (e.g., when generating
> > + a cruft pack or storing unreachable objects as loose), use the
> > + shell to execute the specified command(s). Interpret their
> > + output as object IDs which Git will consider as "recent",
> > + regardless of their age.
>
> >From a potential user's POV, two things seem unclear:
>
> - What does "recenct" mean in this context? Does it just mean
> "precious"?
> - What objects do I need to list? Is it every object I want to keep or
> just the reachable tips?
To answer your questions: recency is referring to the "mtime" of an
object [^1], not whether or not it is precious. I clarified this by
removing the term "recent" from this sentence altogether, to instead
read:
"When considering whether or not to remove an object [...]"
You only need to list the tips, since Git will treat the output of the
hook as input to a traversal which allows for missing objects. Any
object visited along that traversal will be kept in the repository and
rescued from deletion. I tried to clarify this by adding a final
sentence (emphasis mine):
"By treating their mtimes as "now", any objects **(and their
descendants)** mentioned in the output will be kept regardless of
their true age."
> In the code changes, I noticed a few out-of-date references to "cruft
> tips", but everything else looked reasonable to me.
Thanks, I'll clean those up and resubmit it with the above fixes
squashed in.
Thanks,
Taylor
[^1]: an object's mtime is the most recent of (1) the st_mtime of a its
loose object file, if it exists, (2) the st_mtime of any non-cruft
pack(s) that contain that object, or (3) the value listed in the .mtimes
file of the cruft pack corresponding to that object's entry.
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
@ 2018-11-28 3:58 5% ` Junio C Hamano
2018-11-28 21:54 5% ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-11-28 3:58 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Per Lundberg, brian m. carlson, git@vger.kernel.org, Steffen Jost,
Joshua Jensen, Matthieu Moy, Clemens Buchacher, Holger Hellmuth,
Kevin Ballard, Nguyễn Thái Ngọc Duy
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> What do you think about some patch like that which retains the plumbing
> behavior for things like read-tree, doesn't introduce "precious" or
> "trashable", and just makes you specify "[checkout|merge|...] --force"
> in cases where we'd have clobbering?
Whether you like it or not, don't people's automation use tons of
invocations of "git merge", "git checkout", etc.? You'd be breaking
them by such a change. Other than that, if we never had Git before
and do not have to worry about existing users, I'd think it would be
a lot closer to the ideal than today's system if "checkout <tree>
foo.o" rejected overwriting "foo.o" that is not tracked in the
current index but matches an ignore pattern, and required a
"--force" option to overwrite it.
A user, during a conflict resolution, may say "I want this 'git
checkout foo/' to ignore conflicted paths in that directory, so I
would give "--force" option to it, but now "--force" also implies
that I am willing to clobber ignored paths, which means I cannot use
it".
I would think that a proper automation needs per-path hint from the
user and/or the project, not just a single-size-fits-all --force
option, and "unlike all the *.o ignored files that are expendable,
this vendor-supplied-object.o is not" is one way to give such a
per-path hint.
> This would give scripts which relied on our stable plumbing consistent
> behavior, while helping users who're using our main porcelain not to
> lose data. I could then add a --force option to the likes of read-tree
> (on by default), so you could get porcelain-like behavior with
> --no-force.
At that low level, I suspect that a single size fits all "--force"
would work even less well.
^ permalink raw reply [relevance 5%]
* [PATCH v3 14/22] worktree: add: suppress auto-vivication with --detach and no <branch>
2015-07-17 23:00 5% ` [PATCH v3 13/22] worktree: make --detach mutually exclusive with -b/-B Eric Sunshine
@ 2015-07-17 23:00 5% ` Eric Sunshine
1 sibling, 0 replies; 200+ results
From: Eric Sunshine @ 2015-07-17 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Duy Nguyen, Michael J Gruber, Eric Sunshine
Fix oversight where branch auto-vivication incorrectly kicks in when
--detach is specified and <branch> omitted. Instead, treat:
git worktree add --detach <path>
as shorthand for:
git worktree add --detach <path> HEAD
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
New in v3.
builtin/worktree.c | 2 +-
t/t2025-worktree-add.sh | 14 ++++++++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 813e016..83484ad 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -308,7 +308,7 @@ static int add(int ac, const char **av, const char *prefix)
if (opts.force_new_branch)
opts.new_branch = new_branch_force;
- if (ac < 2 && !opts.new_branch) {
+ if (ac < 2 && !opts.new_branch && !opts.detach) {
int n;
const char *s = worktree_basename(path, &n);
opts.new_branch = xstrndup(s, n);
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 249e454..8267411 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -153,6 +153,14 @@ test_expect_success '"add -b" with <branch> omitted' '
test_cmp_rev HEAD burble
'
+test_expect_success '"add --detach" with <branch> omitted' '
+ git worktree add --detach fishhook &&
+ git rev-parse HEAD >expected &&
+ git -C fishhook rev-parse HEAD >actual &&
+ test_cmp expected actual &&
+ test_must_fail git -C fishhook symbolic-ref HEAD
+'
+
test_expect_success '"add" with <branch> omitted' '
git worktree add wiffle/bat &&
test_cmp_rev HEAD bat
@@ -167,6 +175,12 @@ test_expect_success '"add" auto-vivify does not clobber existing branch' '
test_path_is_missing precious
'
+test_expect_success '"add" no auto-vivify with --detach and <branch> omitted' '
+ git worktree add --detach mish/mash &&
+ test_must_fail git rev-parse mash -- &&
+ test_must_fail git -C mish/mash symbolic-ref HEAD
+'
+
test_expect_success '"add" -b/-B mutually exclusive' '
test_must_fail git worktree add -b poodle -B poodle bamboo master
'
--
2.5.0.rc2.378.g0af52e8
^ permalink raw reply related [relevance 5%]
* [PATCH v2 28/33] ref_transaction_update(): check refname_is_safe() at a minimum
@ 2016-05-06 16:14 5% ` Michael Haggerty
0 siblings, 0 replies; 200+ results
From: Michael Haggerty @ 2016-05-06 16:14 UTC (permalink / raw)
To: Junio C Hamano, David Turner
Cc: Jeff King, Nguyễn Thái Ngọc Duy, Ramsay Jones,
git, Michael Haggerty
If the user has asked that a new value be set for a reference, we use
check_refname_format() to verify that the reference name satisfies all
of the rules. But in other cases, at least check that refname_is_safe().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
refs.c | 5 +++--
t/t1400-update-ref.sh | 2 +-
t/t1430-bad-ref-name.sh | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 7c4eeb1..842c5c7 100644
--- a/refs.c
+++ b/refs.c
@@ -805,8 +805,9 @@ int ref_transaction_update(struct ref_transaction *transaction,
{
assert(err);
- if (new_sha1 && !is_null_sha1(new_sha1) &&
- check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ if ((new_sha1 && !is_null_sha1(new_sha1)) ?
+ check_refname_format(refname, REFNAME_ALLOW_ONELEVEL) :
+ !refname_is_safe(refname)) {
strbuf_addf(err, "refusing to update ref with bad name '%s'",
refname);
return -1;
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 40b0cce..08bd8fd 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -23,7 +23,7 @@ test_expect_success setup '
m=refs/heads/master
n_dir=refs/heads/gu
n=$n_dir/fixes
-outside=foo
+outside=refs/foo
test_expect_success \
"create $m" \
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index 25ddab4..8937e25 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@ -285,7 +285,7 @@ test_expect_success 'update-ref -d cannot delete non-ref in .git dir' '
echo precious >expect &&
test_must_fail git update-ref -d my-private-file >output 2>error &&
test_must_be_empty output &&
- test_i18ngrep -e "cannot lock .*: unable to resolve reference" error &&
+ test_i18ngrep -e "refusing to update ref with bad name" error &&
test_cmp expect .git/my-private-file
'
--
2.8.1
^ permalink raw reply related [relevance 5%]
* Re: [PATCH 1/1] Introduce "precious" file concept
2019-02-20 9:41 5% ` Duy Nguyen
@ 2019-02-20 9:36 5% ` Steffen Jost
1 sibling, 0 replies; 200+ results
From: Steffen Jost @ 2019-02-20 9:36 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, Junio C Hamano
Cc: Duy Nguyen, Git Mailing List, Per Lundberg, Joshua Jensen,
Matthieu Moy, Clemens Buchacher, Holger Hellmuth, Kevin Ballard
On 20.02.19 10:19, Ævar Arnfjörð Bjarmason wrote:
> Most git users are at the level of only knowing very basic
> add/commit/pull/push command interaction. I feel strongly that we need
> to make our tools safe to use by default, and not require some
> relatively advanced "precious"/attribute facility to be carefully
> configured in advance so we don't throw away uncommitted work on the
> likes of merge/checkout.
>
> 1. https://public-inbox.org/git/87zhuf3gs0.fsf@evledraar.gmail.com/
> 2. https://public-inbox.org/git/871s7r4wuv.fsf@evledraar.gmail.com/
>
+1
Please consider that silently deleting files is a no-go.
I teach computer science, and our switch from subversion to git for our second year programming projects caused a lot of grief, so much that my colleagues consider switching back to subversion as the point of first contact with revisioning.
Silently deleting partially revisioned files is a major source: students regularly destroy IDE or OS specific config files that they cannot restore themselves. (Project participants use all kinds of different IDEs on different OSs and thus have all kinds of weird hidden files that always manage to get checked into the repository, wreaking havoc on another's machine. So they get deleted and thus disturb the student that needed those files.) We do provide a huge .gitignore that ought to prevent this, but despite numerous warnings they only add it later, which then causes previously checked-in files to be lost upon switching between branches.
Please, by default, issue at least a warning before files are irrevocably los - or maybe keep a local snapshot of everything for the last few checkout in order to undo them?
Thanks,
Steffen.
--
+49-89-2180-9139
http://www.tcs.ifi.lmu.de/~jost/
Lehr- und Forschungseinheit für Theoretische Informatik
Ludwig-Maximilians-Universität München
Oettingenstr. 67 (E111)
80538 München
BAVARIA
^ permalink raw reply [relevance 5%]
* [PATCH v2 3/6] t1302: make tests more robust with new extensions
@ 2024-01-10 9:01 5% ` Patrick Steinhardt
0 siblings, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-01-10 9:01 UTC (permalink / raw)
To: git; +Cc: Taylor Blau, Eric Sunshine
[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]
In t1302 we exercise logic around "core.repositoryFormatVersion" and
extensions. These tests are not particularly robust against extensions
like the newly introduced "refStorage" extension.
Refactor the tests to be more robust:
- Check the DEFAULT_REPO_FORMAT prereq to determine the expected
repository format version. This helps to ensure that we only need to
update the prereq in a central place when new extensions are added.
- Use a separate repository to rewrite ".git/config" to test
combinations of the repository format version and extensions. This
ensures that we don't break the main test repository.
- Do not rewrite ".git/config" when exercising the "preciousObjects"
extension.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/t1302-repo-version.sh | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index 179474fa65..7c680c91c4 100755
--- a/t/t1302-repo-version.sh
+++ b/t/t1302-repo-version.sh
@@ -28,7 +28,12 @@ test_expect_success 'setup' '
'
test_expect_success 'gitdir selection on normal repos' '
- test_oid version >expect &&
+ if test_have_prereq DEFAULT_REPO_FORMAT
+ then
+ echo 0
+ else
+ echo 1
+ fi >expect &&
git config core.repositoryformatversion >actual &&
git -C test config core.repositoryformatversion >actual2 &&
test_cmp expect actual &&
@@ -79,8 +84,13 @@ mkconfig () {
while read outcome version extensions; do
test_expect_success "$outcome version=$version $extensions" "
- mkconfig $version $extensions >.git/config &&
- check_${outcome}
+ test_when_finished 'rm -rf extensions' &&
+ git init extensions &&
+ (
+ cd extensions &&
+ mkconfig $version $extensions >.git/config &&
+ check_${outcome}
+ )
"
done <<\EOF
allow 0
@@ -94,7 +104,8 @@ allow 1 noop-v1
EOF
test_expect_success 'precious-objects allowed' '
- mkconfig 1 preciousObjects >.git/config &&
+ git config core.repositoryFormatVersion 1 &&
+ git config extensions.preciousObjects 1 &&
check_allow
'
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [relevance 5%]
* [PATCH] Teach checkout the -n|--dry-run option
@ 2011-05-06 22:12 5% Jens Lehmann
0 siblings, 0 replies; 200+ results
From: Jens Lehmann @ 2011-05-06 22:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This option can be used to determine if checking out a branch or commit
would touch files which are modified in the work tree. It doesn't change
the work tree contents or the index, so it can only tell if the checkout
would succeed using trivial merges.
It can neither be used when checking out only certain paths nor together
with the '-m' option.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
This is a repost of a RFC patch from Sep 04, 2010 I did not receive any
responses upon:
I need this new option for the recursive submodule checkout. Denying a
checkout inside a submodule just because it has modifications is a too
limiting condition (and it is way too expensive to check the whole tree,
just looking at those paths going to be changed by the checkout should
be much faster, especially for large submodules).
IMO the same behavior that applies for a checkout in the superproject
should apply for the checkout inside the submodule: no local changes
may be overwritten by the checkout (and the HEAD must match the commit
recorded in the superproject, but that is handled elsewhere).
To be able to test that, I added the -n|--dry-run option to checkout.
I think I found all relevant places, but a few more eyeballs are highly
appreciated as I am not very familiar with this part of the code.
A thing I'm not so sure about is the output of show_local_changes(),
with -n it doesn't show the changes as they would have been *after* the
- not executed - checkout but *without* having done it.
Is that a problem here?
Documentation/git-checkout.txt | 15 ++++++++++++---
builtin/checkout.c | 20 +++++++++++++++-----
t/t2018-checkout-branch.sh | 23 +++++++++++++++++++++++
3 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 1063f69..ae58762 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,9 +8,9 @@ git-checkout - Checkout a branch or paths to the working tree
SYNOPSIS
--------
[verse]
-'git checkout' [-q] [-f] [-m] [<branch>]
-'git checkout' [-q] [-f] [-m] [--detach] [<commit>]
-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
+'git checkout' [-q] [-f] [-m|-n] [<branch>]
+'git checkout' [-q] [-f] [-m|-n] [--detach] [<commit>]
+'git checkout' [-q] [-f] [-m|-n] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' --patch [<tree-ish>] [--] [<paths>...]
@@ -79,6 +79,13 @@ OPTIONS
When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.
+-n::
+--dry-run::
+ Don't really checkout the file(s), just check if it would succeed
+ using only trivial merges. Using this option will not touch the work
+ tree or the index. The command will fail when the checkout would change
+ locally modified files. This option can not be used together with `-m`.
+
--ours::
--theirs::
When checking out paths from the index, check out stage #2
@@ -167,6 +174,8 @@ should result in deletion of the path).
+
When checking out paths from the index, this option lets you recreate
the conflicted merge in the specified paths.
++
+This option does not work together with '-n'.
--conflict=<style>::
The same as --merge option above, but changes the way the
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 38632fc..01175d1 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -33,6 +33,7 @@ struct checkout_opts {
int force_detach;
int writeout_stage;
int writeout_error;
+ int dry_run;
/* not set by parse_options */
int branch_exists;
@@ -373,6 +374,8 @@ static int merge_working_tree(struct checkout_opts *opts,
resolve_undo_clear();
if (opts->force) {
+ if (opts->dry_run)
+ return 0;
ret = reset_tree(new->commit->tree, opts, 1);
if (ret)
return ret;
@@ -397,7 +400,7 @@ static int merge_working_tree(struct checkout_opts *opts,
/* 2-way merge to the new branch */
topts.initial_checkout = is_cache_unborn();
- topts.update = 1;
+ topts.update = !opts->dry_run;
topts.merge = 1;
topts.gently = opts->merge && old->commit;
topts.verbose_update = !opts->quiet;
@@ -471,8 +474,8 @@ static int merge_working_tree(struct checkout_opts *opts,
}
}
- if (write_cache(newfd, active_cache, active_nr) ||
- commit_locked_index(lock_file))
+ if (!opts->dry_run && (write_cache(newfd, active_cache, active_nr) ||
+ commit_locked_index(lock_file)))
die(_("unable to write new index file"));
if (!opts->force && !opts->quiet)
@@ -732,7 +735,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
}
ret = merge_working_tree(opts, &old, new);
- if (ret)
+ if (ret || opts->dry_run)
return ret;
if (!opts->quiet && !old.path && old.commit && new->commit != old.commit)
@@ -941,6 +944,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('m', "merge", &opts.merge, "perform a 3-way merge with the new branch"),
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
+ OPT_BOOLEAN('n', "dry-run", &opts.dry_run, "show if the checkout would fail because it touches locally modified files"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
{ OPTION_BOOLEAN, 0, "guess", &dwim_new_local_branch, NULL,
"second guess 'git checkout no-such-branch'",
@@ -967,7 +971,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.new_branch_force)
opts.new_branch = opts.new_branch_force;
- if (patch_mode && (opts.track > 0 || opts.new_branch
+ if (patch_mode && (opts.track > 0 || opts.new_branch || opts.dry_run
|| opts.new_branch_log || opts.merge || opts.force
|| opts.force_detach))
die (_("--patch is incompatible with all other options"));
@@ -1008,6 +1012,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.force && opts.merge)
die(_("git checkout: -f and -m are incompatible"));
+ if (opts.merge && opts.dry_run)
+ die("git checkout: -m and -n are incompatible");
+
/*
* Extract branch name from command line arguments, so
* all that is left is pathspecs.
@@ -1060,6 +1067,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (1 < !!opts.writeout_stage + !!opts.force + !!opts.merge)
die(_("git checkout: --ours/--theirs, --force and --merge are incompatible when\nchecking out of the index."));
+ if (opts.dry_run)
+ die("git checkout: updating paths is incompatible with -n.");
+
return checkout_paths(source_tree, pathspec, &opts);
}
diff --git a/t/t2018-checkout-branch.sh b/t/t2018-checkout-branch.sh
index fa69016..61c82ef 100755
--- a/t/t2018-checkout-branch.sh
+++ b/t/t2018-checkout-branch.sh
@@ -169,4 +169,27 @@ test_expect_success 'checkout -f -B to an existing branch with mergeable changes
test_must_fail test_dirty_mergeable
'
+test_expect_success 'checkout -n/--dry-run does not change work tree or index' '
+ echo precious >expect &&
+ echo precious >file1 &&
+ test_must_fail git checkout -n branch1 &&
+ test_cmp expect file1 &&
+ git checkout --dry-run -f branch1 &&
+ test_cmp expect file1 &&
+ test_must_fail git checkout -b new_branch --dry-run branch1 &&
+ test_cmp expect file1 &&
+ git checkout -b new_branch -n -f branch1 &&
+ test_cmp expect file1 &&
+ git checkout -f branch1 &&
+ git status -s -uno > actual &&
+ ! test -s actual &&
+ git checkout -n HEAD^ &&
+ git status -s -uno > actual &&
+ ! test -s actual
+'
+
+test_expect_success 'checkout -n/--dry-run is not allowed when checking out only certain paths' '
+ test_must_fail git checkout -n branch1 file1 &&
+ test_must_fail git checkout -n HEAD file1
+'
test_done
--
1.7.5.1.174.g799a9
^ permalink raw reply related [relevance 5%]
* Re: [PATCH v4 2/4] core.fsync: introduce granular fsync control
@ 2022-02-11 21:18 5% ` Neeraj Singh
0 siblings, 0 replies; 200+ results
From: Neeraj Singh @ 2022-02-11 21:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Neeraj Singh via GitGitGadget, Git List, Randall S. Becker,
Bagas Sanjaya, Elijah Newren,
Ævar Arnfjörð Bjarmason, Patrick Steinhardt,
Neeraj K. Singh
On Tue, Feb 1, 2022 at 5:42 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I am not quite sure if this is way too complex (e.g. what does it
> > mean that we do not care much about loose-object safety while we do
> > care about commit-graph files?) and at the same time it is too
> > limited (e.g. if it makes sense to say a class of items deserve more
> > protection than another class of items, don't we want to be able to
> > say "class X is ultra-precious so use method A on them, while class
> > Y is mildly precious and use method B on them, everything else are
> > not that important and doing the default thing is just fine").
> >
> > If we wanted to allow the "matrix" kind of flexibility,...
>
> To continue with the thinking aloud...
>
> Sometimes configuration flexibility is truly needed, but often it is
> just a sign of designer being lazy and not thinking it through as an
> end-user facing problem. In other words, "I am giving enough knobs
> to you, so it is up to you to express your policy in whatever way
> you want with the knobs provided" is a very irresponsible thing to
> tell end-users.
>
> And this one smells like the case of a lazy design.
>
> It may be that it makes sense in some workflows to protect
> commit-graph files less than object files and pack.idx files can be
> corrupted as long as pack.pack files are adequately protected
> because the former can be recomputed from the latter, but in no
> workflows, the reverse would be true. Yet the design gives such
> needless flexibility, which makes it hard for lay end-users to
> choose the best combination and allows them to protect .idx files
> more than .pack files by mistake, for example.
>
> I am wondering if the classification itself introduced by this step
> actually can form a natural and linear progression of safe-ness. By
> default, we'd want _all_ classes of things to be equally safe, but
> at one level down, there is "protect things that are not
> recomputable, but recomputable things can be left to the system"
> level, and there would be even riskier "protect packs as it would
> hurt a _lot_ to lose them, but losing loose ones will typically lose
> only the most recent work, and they are less valuable" level.
>
> If we, as the Git experts, spend extra brain cycles to come up with
> an easy to understand spectrum of performance vs durability
> trade-off, end-users won't have to learn the full flexibility and
> easily take the advice from experts. They just need to say what
> level of durability they want (or how much durability they can risk
> in exchange for an additional throughput), and leave the rest to us.
>
> On the core.fsyncMethod side, the same suggestion applies.
>
> Once we know the desired level of performance vs durability
> trade-off from the user, we, as the impolementors, should know the
> best method, for each class of items, to achieve that durability on
> each platform when writing it to the storage, without exposing the
> low level details of the implementation that only the Git folks need
> to be aware of.
>
> So, from the end-user UI perspective, I'd very much prefer if we can
> just come up with a single scalar variable, (say "fsync.durability"
> that ranges from "conservative" to "performance") that lets our
> users express the level of durability desired. The combination of
> core.fsyncMethod and core.fsync are one variable too many, and the
> latter being a variable that takes a list of things as its value
> makes it even worse to sell to the end users.
I see the value in simplifying the core.fsync configuration to a
single scalar knob of preciousness. The main motivation for this more
granular scheme is that I didn't think the current configuration
follows a sensible principle. We should be fsyncing the loose objects,
index, refs, and config files in addition to what we're already
syncing today. On macOS, we should be doing a full hardware flush if
we've said we want to fsync. But you expressed the notion in [1] that
we don't want to degrade the performance of the vast majority of users
who are happy with the current "unprincipled but mostly works"
configuration. I agree with that sentiment, but it leads to a design
where we can express the current configuration, which does not follow
a scalar hierarchy.
The aggregate core.fsync options are meant to provide a way for us to
recommend a sensible configuration to the user without having to get
into the intricacies of repo layout. Maybe we can define and document
aggregate options that make sense in terms of a scalar level of
preciousness.
One reason to keep core.fsyncMethod separate from the core.fsync knob
is that it's more a property of the system and FS the repo is on,
rather than the user's value of the repo. We could try to auto-detect
some known filesystems that might support batch mode using 'statfs',
but having a table like that in Git would go out of date over time.
Please let me know what you think about these justifications for the
current design. I'd be happy to make a change if the current
constraint of "keep the default config the same" can be relaxed in
some way. I'd also be happy to go back to some variation of
expressing 'core.fsyncObjectFiles = batch' and leaving the rest of
fsync story alone.
Thanks,
Neeraj
[1] https://lore.kernel.org/git/xmqqtuilyfls.fsf@gitster.g/
^ permalink raw reply [relevance 5%]
* [PATCH 19/24] refs.c: allow listing and deleting badly named refs
@ 2014-10-02 2:28 5% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2014-10-02 2:28 UTC (permalink / raw)
To: Ronnie Sahlberg; +Cc: git@vger.kernel.org, Michael Haggerty
From: Ronnie Sahlberg <sahlberg@google.com>
Date: Wed, 3 Sep 2014 11:45:43 -0700
We currently do not handle badly named refs well:
$ cp .git/refs/heads/master .git/refs/heads/master.....@\*@\\.
$ git branch
fatal: Reference has invalid format: 'refs/heads/master.....@*@\.'
$ git branch -D master.....@\*@\\.
error: branch 'master.....@*@\.' not found.
Users cannot recover from a badly named ref without manually finding
and deleting the loose ref file or appropriate line in packed-refs.
Making that easier will make it easier to tweak the ref naming rules
in the future, for example to forbid shell metacharacters like '`'
and '"', without putting people in a state that is hard to get out of.
So allow "git branch --list" to show these refs and to allow "git
branch -d/-D" and "git update-ref -d" to delete them. Other commands
(for example to rename refs) will continue to not handle these refs
but can be changed in later patches.
Details:
In resolving functions, refuse to resolve refs that don't pass the
check-ref-format(1) check unless the new RESOLVE_REF_ALLOW_BAD_NAME
flag is passed. Even with RESOLVE_REF_ALLOW_BAD_NAME, refuse to
resolve refs that escape the refs/ directory and do not match the
pattern [A-Z_]* (think "HEAD" and "MERGE_HEAD").
In locking functions, refuse to act on badly named refs unless they
are being deleted and either are in the refs/ directory or match [A-Z_]*.
Just like other invalid refs, flag resolved, badly named refs with the
REF_ISBROKEN flag, treat them as resolving to null_sha1, and skip them
in all iteration functions except for for_each_rawref.
Flag badly named refs with a REF_BAD_NAME flag to make it easier for
future callers to notice and handle them specially.
In the transaction API, refuse to create or update badly named refs,
but allow deleting them (unless they escape refs/ and don't match
[A-Z_]*).
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Since v21:
- clarified change description
- handle REF_ISBROKEN case too when printing "Deleted branch" message
- tighten fallback check, so commands like 'git branch -d ../../config'
won't work
- use REF_BAD_NAME so it's easier for callers (like for-each-ref in a
later patch) to notice that we decided a ref's name was bad
- set errno when failing to find ref in the packed-refs file
- consistently don't set REF_ISBROKEN for missing refs
- consistently clear sha1 when successfully resolving a badly named ref
- treat refs with bad names encountered as part of symref resolution the
same as such refs explicitly named
- always allow safe bad names when trying to lock a ref for deletion
(though some callers don't get that far yet)
- clearer API docs, more tests
builtin/branch.c | 9 +--
cache.h | 14 ++++-
refs.c | 148 ++++++++++++++++++++++++++++++++++++++----------
refs.h | 8 ++-
t/t1430-bad-ref-name.sh | 125 +++++++++++++++++++++++++++++++++++++++-
5 files changed, 265 insertions(+), 39 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index a0c5601..94aaea1 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -236,7 +236,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
name = mkpathdup(fmt, bname.buf);
target = resolve_ref_unsafe(name,
RESOLVE_REF_READING
- | RESOLVE_REF_NO_RECURSE,
+ | RESOLVE_REF_NO_RECURSE
+ | RESOLVE_REF_ALLOW_BAD_NAME,
sha1, &flags);
if (!target) {
error(remote_branch
@@ -246,7 +247,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
continue;
}
- if (!(flags & REF_ISSYMREF) &&
+ if (!(flags & (REF_ISSYMREF|REF_ISBROKEN)) &&
check_branch_commit(bname.buf, name, sha1, head_rev, kinds,
force)) {
ret = 1;
@@ -266,8 +267,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
? _("Deleted remote branch %s (was %s).\n")
: _("Deleted branch %s (was %s).\n"),
bname.buf,
- (flags & REF_ISSYMREF)
- ? target
+ (flags & REF_ISBROKEN) ? "broken"
+ : (flags & REF_ISSYMREF) ? target
: find_unique_abbrev(sha1, DEFAULT_ABBREV));
}
delete_branch_config(bname.buf);
diff --git a/cache.h b/cache.h
index 5ca7f2b..0c0ac60 100644
--- a/cache.h
+++ b/cache.h
@@ -978,16 +978,26 @@ extern int read_ref(const char *refname, unsigned char *sha1);
* If flags is non-NULL, set the value that it points to the
* combination of REF_ISPACKED (if the reference was found among the
* packed references), REF_ISSYMREF (if the initial reference was a
- * symbolic reference) and REF_ISBROKEN (if the ref is malformed).
+ * symbolic reference), REF_BAD_NAME (if the reference name is ill
+ * formed --- see RESOLVE_REF_ALLOW_BAD_NAME below), and REF_ISBROKEN
+ * (if the ref is malformed).
*
* If ref is not a properly-formatted, normalized reference, return
* NULL. If more than MAXDEPTH recursive symbolic lookups are needed,
* give up and return NULL.
*
- * errno is set to something meaningful on error.
+ * RESOLVE_REF_ALLOW_BAD_NAME allows resolving refs even when their
+ * name is invalid according to git-check-ref-format(1). If the name
+ * is bad then the value stored in sha1 will be null_sha1 and the
+ * REF_ISBROKEN and REF_BAD_NAME flags will be set.
+ *
+ * Even with RESOLVE_REF_ALLOW_BAD_NAME, names that escape the refs/
+ * directory and do not consist of all caps and underscores cannot be
+ * resolved. The function returns NULL for such ref names.
*/
#define RESOLVE_REF_READING 0x01
#define RESOLVE_REF_NO_RECURSE 0x02
+#define RESOLVE_REF_ALLOW_BAD_NAME 0x04
extern const char *resolve_ref_unsafe(const char *ref, int resolve_flags, unsigned char *sha1, int *flags);
extern char *resolve_refdup(const char *ref, int resolve_flags, unsigned char *sha1, int *flags);
diff --git a/refs.c b/refs.c
index 94d6d89..0d3abb1 100644
--- a/refs.c
+++ b/refs.c
@@ -185,8 +185,8 @@ struct ref_dir {
/*
* Bit values for ref_entry::flag. REF_ISSYMREF=0x01,
- * REF_ISPACKED=0x02, and REF_ISBROKEN=0x04 are public values; see
- * refs.h.
+ * REF_ISPACKED=0x02, REF_ISBROKEN=0x04 and REF_BAD_NAME=0x08 are
+ * public values; see refs.h.
*/
/*
@@ -194,16 +194,16 @@ struct ref_dir {
* the correct peeled value for the reference, which might be
* null_sha1 if the reference is not a tag or if it is broken.
*/
-#define REF_KNOWS_PEELED 0x08
+#define REF_KNOWS_PEELED 0x10
/* ref_entry represents a directory of references */
-#define REF_DIR 0x10
+#define REF_DIR 0x20
/*
* Entry has not yet been read from disk (used only for REF_DIR
* entries representing loose references)
*/
-#define REF_INCOMPLETE 0x20
+#define REF_INCOMPLETE 0x40
/*
* A ref_entry represents either a reference or a "subdirectory" of
@@ -272,6 +272,37 @@ static struct ref_dir *get_ref_dir(struct ref_entry *entry)
return dir;
}
+static int escapes_cwd(const char *path) {
+ char *buf;
+ int result;
+
+ if (is_absolute_path(path))
+ return 1;
+ buf = xmalloc(strlen(path) + 1);
+ result = !!normalize_path_copy(buf, path);
+ free(buf);
+ return result;
+}
+
+/*
+ * Check if a refname is safe.
+ * For refs that start with "refs/" we consider it safe as long as the rest
+ * of the path components does not allow it to escape from this directory.
+ * For all other refs we only consider them safe iff they only contain
+ * upper case characters and '_'.
+ */
+static int refname_is_safe(const char *refname)
+{
+ if (starts_with(refname, "refs/"))
+ return !escapes_cwd(refname + strlen("refs/"));
+ while (*refname) {
+ if (!isupper(*refname) && *refname != '_')
+ return 0;
+ refname++;
+ }
+ return 1;
+}
+
static struct ref_entry *create_ref_entry(const char *refname,
const unsigned char *sha1, int flag,
int check_name)
@@ -282,6 +313,8 @@ static struct ref_entry *create_ref_entry(const char *refname,
if (check_name &&
check_refname_format(refname, REFNAME_ALLOW_ONELEVEL))
die("Reference has invalid format: '%s'", refname);
+ if (!check_name && !refname_is_safe(refname))
+ die("Reference has invalid name: '%s'", refname);
len = strlen(refname) + 1;
ref = xmalloc(sizeof(struct ref_entry) + len);
hashcpy(ref->u.value.sha1, sha1);
@@ -1051,7 +1084,13 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
refname = parse_ref_line(refline, sha1);
if (refname) {
- last = create_ref_entry(refname, sha1, REF_ISPACKED, 1);
+ int flag = REF_ISPACKED;
+
+ if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ hashclr(sha1);
+ flag |= REF_BAD_NAME | REF_ISBROKEN;
+ }
+ last = create_ref_entry(refname, sha1, flag, 0);
if (peeled == PEELED_FULLY ||
(peeled == PEELED_TAGS && starts_with(refname, "refs/tags/")))
last->flag |= REF_KNOWS_PEELED;
@@ -1189,8 +1228,13 @@ static void read_loose_refs(const char *dirname, struct ref_dir *dir)
hashclr(sha1);
flag |= REF_ISBROKEN;
}
+ if (check_refname_format(refname.buf,
+ REFNAME_ALLOW_ONELEVEL)) {
+ hashclr(sha1);
+ flag |= REF_BAD_NAME | REF_ISBROKEN;
+ }
add_entry_to_dir(dir,
- create_ref_entry(refname.buf, sha1, flag, 1));
+ create_ref_entry(refname.buf, sha1, flag, 0));
}
strbuf_setlen(&refname, dirnamelen);
}
@@ -1309,10 +1353,10 @@ static struct ref_entry *get_packed_ref(const char *refname)
* A loose ref file doesn't exist; check for a packed ref. The
* options are forwarded from resolve_safe_unsafe().
*/
-static const char *handle_missing_loose_ref(const char *refname,
- int resolve_flags,
- unsigned char *sha1,
- int *flags)
+static int resolve_missing_loose_ref(const char *refname,
+ int resolve_flags,
+ unsigned char *sha1,
+ int *flags)
{
struct ref_entry *entry;
@@ -1325,14 +1369,15 @@ static const char *handle_missing_loose_ref(const char *refname,
hashcpy(sha1, entry->u.value.sha1);
if (flags)
*flags |= REF_ISPACKED;
- return refname;
+ return 0;
}
/* The reference is not a packed reference, either. */
if (resolve_flags & RESOLVE_REF_READING) {
- return NULL;
+ errno = ENOENT;
+ return -1;
} else {
hashclr(sha1);
- return refname;
+ return 0;
}
}
@@ -1343,13 +1388,29 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
ssize_t len;
char buffer[256];
static char refname_buffer[256];
+ int bad_name = 0;
if (flags)
*flags = 0;
if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
- errno = EINVAL;
- return NULL;
+ if (flags)
+ *flags |= REF_BAD_NAME;
+
+ if (!(resolve_flags & RESOLVE_REF_ALLOW_BAD_NAME) ||
+ !refname_is_safe(refname)) {
+ errno = EINVAL;
+ return NULL;
+ }
+ /*
+ * dwim_ref() uses REF_ISBROKEN to distinguish between
+ * missing refs and refs that were present but invalid,
+ * to complain about the latter to stderr.
+ *
+ * We don't know whether the ref exists, so don't set
+ * REF_ISBROKEN yet.
+ */
+ bad_name = 1;
}
for (;;) {
char path[PATH_MAX];
@@ -1375,11 +1436,17 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
*/
stat_ref:
if (lstat(path, &st) < 0) {
- if (errno == ENOENT)
- return handle_missing_loose_ref(refname,
- resolve_flags, sha1, flags);
- else
+ if (errno != ENOENT)
return NULL;
+ if (resolve_missing_loose_ref(refname, resolve_flags,
+ sha1, flags))
+ return NULL;
+ if (bad_name) {
+ hashclr(sha1);
+ if (flags)
+ *flags |= REF_ISBROKEN;
+ }
+ return refname;
}
/* Follow "normalized" - ie "refs/.." symlinks by hand */
@@ -1452,6 +1519,11 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
errno = EINVAL;
return NULL;
}
+ if (bad_name) {
+ hashclr(sha1);
+ if (flags)
+ *flags |= REF_ISBROKEN;
+ }
return refname;
}
if (flags)
@@ -1466,9 +1538,14 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
}
if (check_refname_format(buf, REFNAME_ALLOW_ONELEVEL)) {
if (flags)
- *flags |= REF_ISBROKEN;
- errno = EINVAL;
- return NULL;
+ *flags |= REF_BAD_NAME | REF_ISBROKEN;
+
+ if (!(resolve_flags & RESOLVE_REF_ALLOW_BAD_NAME) ||
+ !refname_is_safe(buf)) {
+ errno = EINVAL;
+ return NULL;
+ }
+ bad_name = 1;
}
}
}
@@ -2101,18 +2178,16 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname,
int missing = 0;
int attempts_remaining = 3;
- if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
- errno = EINVAL;
- return NULL;
- }
-
lock = xcalloc(1, sizeof(struct ref_lock));
lock->lock_fd = -1;
if (mustexist)
resolve_flags |= RESOLVE_REF_READING;
- if (flags & REF_NODEREF && flags & REF_DELETING)
- resolve_flags |= RESOLVE_REF_NO_RECURSE;
+ if (flags & REF_DELETING) {
+ resolve_flags |= RESOLVE_REF_ALLOW_BAD_NAME;
+ if (flags & REF_NODEREF)
+ resolve_flags |= RESOLVE_REF_NO_RECURSE;
+ }
refname = resolve_ref_unsafe(refname, resolve_flags,
lock->old_sha1, &type);
@@ -3465,6 +3540,13 @@ int ref_transaction_update(struct ref_transaction *transaction,
if (have_old && !old_sha1)
die("BUG: have_old is true but old_sha1 is NULL");
+ if (!is_null_sha1(new_sha1) &&
+ check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ strbuf_addf(err, "refusing to update ref with bad name %s",
+ refname);
+ return -1;
+ }
+
update = add_update(transaction, refname);
hashcpy(update->new_sha1, new_sha1);
update->flags = flags;
@@ -3490,6 +3572,12 @@ int ref_transaction_create(struct ref_transaction *transaction,
if (!new_sha1 || is_null_sha1(new_sha1))
die("BUG: create ref with null new_sha1");
+ if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ strbuf_addf(err, "refusing to create ref with bad name %s",
+ refname);
+ return -1;
+ }
+
update = add_update(transaction, refname);
hashcpy(update->new_sha1, new_sha1);
diff --git a/refs.h b/refs.h
index e48d8b9..3b35387 100644
--- a/refs.h
+++ b/refs.h
@@ -56,11 +56,15 @@ struct ref_transaction;
/*
* Reference cannot be resolved to an object name: dangling symbolic
- * reference (directly or indirectly), corrupt reference file, or
- * symbolic reference refers to ill-formatted reference name.
+ * reference (directly or indirectly), corrupt reference file,
+ * reference exists but name is bad, or symbolic reference refers to
+ * ill-formatted reference name.
*/
#define REF_ISBROKEN 0x04
+/* Reference name is not well formed (see git-check-ref-format(1)). */
+#define REF_BAD_NAME 0x08
+
/*
* The signature for the callback function for the for_each_*()
* functions below. The memory pointed to by the refname and sha1
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index c7b19b0..468e856 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@ -4,7 +4,8 @@ test_description='Test handling of ref names that check-ref-format rejects'
. ./test-lib.sh
test_expect_success setup '
- test_commit one
+ test_commit one &&
+ test_commit two
'
test_expect_success 'fast-import: fail on invalid branch name ".badbranchname"' '
@@ -37,6 +38,107 @@ test_expect_success 'fast-import: fail on invalid branch name "bad[branch]name"'
test_must_fail git fast-import <input
'
+test_expect_success 'git branch shows badly named ref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch >output &&
+ grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -d can delete badly named ref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -d broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -D can delete badly named ref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -D broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -D cannot delete non-ref in .git dir' '
+ echo precious >.git/my-private-file &&
+ echo precious >expect &&
+ test_must_fail git branch -D ../../my-private-file &&
+ test_cmp expect .git/my-private-file
+'
+
+test_expect_success 'branch -D cannot delete absolute path' '
+ git branch -f extra &&
+ test_must_fail git branch -D "$(pwd)/.git/refs/heads/extra" &&
+ test_cmp_rev HEAD extra
+'
+
+test_expect_success 'git branch cannot create a badly named ref' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ test_must_fail git branch broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -m cannot rename to a bad ref name' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ test_might_fail git branch -D goodref &&
+ git branch goodref &&
+ test_must_fail git branch -m goodref broken...ref &&
+ test_cmp_rev master goodref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_failure 'branch -m can rename from a bad ref name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -m broken...ref renamed &&
+ test_cmp_rev master renamed &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'push cannot create a badly named ref' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ test_must_fail git push "file://$(pwd)" HEAD:refs/heads/broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_failure 'push --mirror can delete badly named ref' '
+ top=$(pwd) &&
+ git init src &&
+ git init dest &&
+
+ (
+ cd src &&
+ test_commit one
+ ) &&
+ (
+ cd dest &&
+ test_commit two &&
+ git checkout --detach &&
+ cp .git/refs/heads/master .git/refs/heads/broken...ref
+ ) &&
+ git -C src push --mirror "file://$top/dest" &&
+ git -C dest branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'rev-parse skips symref pointing to broken name' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch shadow one &&
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ git symbolic-ref refs/tags/shadow refs/heads/broken...ref &&
+
+ git rev-parse --verify one >expect &&
+ git rev-parse --verify shadow >actual 2>err &&
+ test_cmp expect actual &&
+ test_i18ngrep "ignoring.*refs/tags/shadow" err
+'
+
test_expect_success 'update-ref --no-deref -d can delete reference to broken name' '
git symbolic-ref refs/heads/badname refs/heads/broken...ref &&
test_when_finished "rm -f .git/refs/heads/badname" &&
@@ -45,6 +147,27 @@ test_expect_success 'update-ref --no-deref -d can delete reference to broken nam
test_path_is_missing .git/refs/heads/badname
'
+test_expect_success 'update-ref -d can delete broken name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git update-ref -d refs/heads/broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'update-ref -d cannot delete non-ref in .git dir' '
+ echo precious >.git/my-private-file &&
+ echo precious >expect &&
+ test_must_fail git update-ref -d my-private-file &&
+ test_cmp expect .git/my-private-file
+'
+
+test_expect_success 'update-ref -d cannot delete absolute path' '
+ git branch -f extra &&
+ test_must_fail git update-ref -d "$(pwd)/.git/refs/heads/extra" &&
+ test_cmp_rev HEAD extra
+'
+
test_expect_success 'update-ref --stdin fails create with bad ref name' '
echo "create ~a refs/heads/master" >stdin &&
test_must_fail git update-ref --stdin <stdin 2>err &&
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related [relevance 5%]
* [PATCH 3/6] t1302: make tests more robust with new extensions
@ 2024-01-09 12:17 5% ` Patrick Steinhardt
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-01-09 12:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]
In t1302 we exercise logic around "core.repositoryFormatVersion" and
extensions. These tests are not particularly robust against extensions
like the newly introduced "refStorage" extension.
Refactor the tests to be more robust:
- Check the DEFAULT_REPO_FORMAT prereq to determine the expected
repository format version. This helps to ensure that we only need to
update the prereq in a central place when new extensions are added.
- Use a separate repository to rewrite ".git/config" to test
combinations of the repository format version and extensions. This
ensures that we don't break the main test repository.
- Do not rewrite ".git/config" when exercising the "preciousObjects"
extension.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
t/t1302-repo-version.sh | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index 179474fa65..fb30c87e1b 100755
--- a/t/t1302-repo-version.sh
+++ b/t/t1302-repo-version.sh
@@ -28,7 +28,12 @@ test_expect_success 'setup' '
'
test_expect_success 'gitdir selection on normal repos' '
- test_oid version >expect &&
+ if test_have_prereq DEFAULT_REPO_FORMAT
+ then
+ echo 0
+ else
+ echo 1
+ fi >expect &&
git config core.repositoryformatversion >actual &&
git -C test config core.repositoryformatversion >actual2 &&
test_cmp expect actual &&
@@ -79,8 +84,13 @@ mkconfig () {
while read outcome version extensions; do
test_expect_success "$outcome version=$version $extensions" "
- mkconfig $version $extensions >.git/config &&
- check_${outcome}
+ test_when_finished 'rm -rf extensions' &&
+ git init extensions &&
+ (
+ cd extensions &&
+ mkconfig $version $extensions >.git/config &&
+ check_${outcome}
+ )
"
done <<\EOF
allow 0
@@ -94,7 +104,8 @@ allow 1 noop-v1
EOF
test_expect_success 'precious-objects allowed' '
- mkconfig 1 preciousObjects >.git/config &&
+ git config core.repositoryformatversion 1 &&
+ git config extensions.preciousObjects 1 &&
check_allow
'
--
2.43.GIT
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [relevance 5%]
* Re: [PATCH 1/1] Introduce "precious" file concept
@ 2019-02-20 22:32 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2019-02-20 22:32 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ævar Arnfjörð Bjarmason, Git Mailing List,
Per Lundberg, Steffen Jost, Joshua Jensen, Matthieu Moy,
Clemens Buchacher, Holger Hellmuth, Kevin Ballard
Duy Nguyen <pclouds@gmail.com> writes:
> - surprises sometimes, but in known classes. This is the main use
> case of backup log, where I may accidentally do "git commit
> -amsomething" after carefully preparing the index. Saving overwritten
> files by merge/checkout could be done here as an alternative to
> "garbage" attribute.
The problem with either of these is not the "saving" half, but
"restoring". For different people, and for different cases even to
the same person, granularity of what is perceived as a single action
is different, so "give me the state of my working tree files before
the last operation" is a request that does not have a good
definition. After finishing "git rebase" that replays 3 changes,
one of which needs manual conflict resolution, you may realize that
you made an incorrect resolution for one path but not others. How
would you let the user say "no, I do not want to undo the whole
rebase, I want to go back to the state where I replayed the first
change, saw the conflicts while replaying the second change, and
resolved them in these files, but before touching that last one I
screwed up resolving, so that I can correct"?
Piling many "backups" (or "snapshots") on top of each other is the
easier part; I'd expect that it would be a much harder design
problem to let users make use of them in meaningful ways, and that
is the primary reason why I am skeptical.
^ permalink raw reply [relevance 5%]
* [PATCH 05/21] t1430: improve test coverage of deletion of badly-named refs
@ 2016-03-23 10:04 5% ` Michael Haggerty
0 siblings, 0 replies; 200+ results
From: Michael Haggerty @ 2016-03-23 10:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff, pclouds, Ramsay Jones, Michael Haggerty
Check "branch -d broken...ref"
Check various combinations of
* Deleting using "update-ref -d"
* Deleting using "update-ref --no-deref -d"
* Deleting using "branch -d"
in the following combinations of symref -> ref:
* badname -> broken...ref
* badname -> broken...ref (dangling)
* broken...symref -> master
* broken...symref -> idonotexist (dangling)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
t/t1430-bad-ref-name.sh | 108 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 98 insertions(+), 10 deletions(-)
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index 612cc32..25ddab4 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@ -171,16 +171,6 @@ test_expect_success 'for-each-ref emits warnings for broken names' '
test_i18ngrep "ignoring ref with broken name refs/heads/broken\.\.\.symref" error
'
-test_expect_success 'update-ref --no-deref -d can delete reference to broken name' '
- printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
- test_when_finished "rm -f .git/refs/heads/badname" &&
- test_path_is_file .git/refs/heads/badname &&
- git update-ref --no-deref -d refs/heads/badname >output 2>error &&
- test_path_is_missing .git/refs/heads/badname &&
- test_must_be_empty output &&
- test_must_be_empty error
-'
-
test_expect_success 'update-ref -d can delete broken name' '
cp .git/refs/heads/master .git/refs/heads/broken...ref &&
test_when_finished "rm -f .git/refs/heads/broken...ref" &&
@@ -192,6 +182,104 @@ test_expect_success 'update-ref -d can delete broken name' '
! grep -e "broken\.\.\.ref" output
'
+test_expect_success 'branch -d can delete broken name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -d broken...ref >output 2>error &&
+ test_i18ngrep "Deleted branch broken...ref (was broken)" output &&
+ test_must_be_empty error &&
+ git branch >output 2>error &&
+ ! grep -e "broken\.\.\.ref" error &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'update-ref --no-deref -d can delete symref to broken name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
+ test_when_finished "rm -f .git/refs/heads/badname" &&
+ git update-ref --no-deref -d refs/heads/badname >output 2>error &&
+ test_path_is_missing .git/refs/heads/badname &&
+ test_must_be_empty output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'branch -d can delete symref to broken name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
+ test_when_finished "rm -f .git/refs/heads/badname" &&
+ git branch -d badname >output 2>error &&
+ test_path_is_missing .git/refs/heads/badname &&
+ test_i18ngrep "Deleted branch badname (was refs/heads/broken\.\.\.ref)" output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'update-ref --no-deref -d can delete dangling symref to broken name' '
+ printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
+ test_when_finished "rm -f .git/refs/heads/badname" &&
+ git update-ref --no-deref -d refs/heads/badname >output 2>error &&
+ test_path_is_missing .git/refs/heads/badname &&
+ test_must_be_empty output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'branch -d can delete dangling symref to broken name' '
+ printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
+ test_when_finished "rm -f .git/refs/heads/badname" &&
+ git branch -d badname >output 2>error &&
+ test_path_is_missing .git/refs/heads/badname &&
+ test_i18ngrep "Deleted branch badname (was refs/heads/broken\.\.\.ref)" output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'update-ref -d can delete broken name through symref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ printf "ref: refs/heads/broken...ref\n" >.git/refs/heads/badname &&
+ test_when_finished "rm -f .git/refs/heads/badname" &&
+ git update-ref -d refs/heads/badname >output 2>error &&
+ test_path_is_missing .git/refs/heads/broken...ref &&
+ test_must_be_empty output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'update-ref --no-deref -d can delete symref with broken name' '
+ printf "ref: refs/heads/master\n" >.git/refs/heads/broken...symref &&
+ test_when_finished "rm -f .git/refs/heads/broken...symref" &&
+ git update-ref --no-deref -d refs/heads/broken...symref >output 2>error &&
+ test_path_is_missing .git/refs/heads/broken...symref &&
+ test_must_be_empty output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'branch -d can delete symref with broken name' '
+ printf "ref: refs/heads/master\n" >.git/refs/heads/broken...symref &&
+ test_when_finished "rm -f .git/refs/heads/broken...symref" &&
+ git branch -d broken...symref >output 2>error &&
+ test_path_is_missing .git/refs/heads/broken...symref &&
+ test_i18ngrep "Deleted branch broken...symref (was refs/heads/master)" output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'update-ref --no-deref -d can delete dangling symref with broken name' '
+ printf "ref: refs/heads/idonotexist\n" >.git/refs/heads/broken...symref &&
+ test_when_finished "rm -f .git/refs/heads/broken...symref" &&
+ git update-ref --no-deref -d refs/heads/broken...symref >output 2>error &&
+ test_path_is_missing .git/refs/heads/broken...symref &&
+ test_must_be_empty output &&
+ test_must_be_empty error
+'
+
+test_expect_success 'branch -d can delete dangling symref with broken name' '
+ printf "ref: refs/heads/idonotexist\n" >.git/refs/heads/broken...symref &&
+ test_when_finished "rm -f .git/refs/heads/broken...symref" &&
+ git branch -d broken...symref >output 2>error &&
+ test_path_is_missing .git/refs/heads/broken...symref &&
+ test_i18ngrep "Deleted branch broken...symref (was refs/heads/idonotexist)" output &&
+ test_must_be_empty error
+'
+
test_expect_success 'update-ref -d cannot delete non-ref in .git dir' '
echo precious >.git/my-private-file &&
echo precious >expect &&
--
2.8.0.rc3
^ permalink raw reply related [relevance 5%]
* [PATCH 20/25] refs.c: allow listing and deleting badly named refs
@ 2014-10-15 0:54 5% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2014-10-15 0:54 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Ronnie Sahlberg, Junio C Hamano
From: Ronnie Sahlberg <sahlberg@google.com>
Date: Wed, 3 Sep 2014 11:45:43 -0700
We currently do not handle badly named refs well:
$ cp .git/refs/heads/master .git/refs/heads/master.....@\*@\\.
$ git branch
fatal: Reference has invalid format: 'refs/heads/master.....@*@\.'
$ git branch -D master.....@\*@\\.
error: branch 'master.....@*@\.' not found.
Users cannot recover from a badly named ref without manually finding
and deleting the loose ref file or appropriate line in packed-refs.
Making that easier will make it easier to tweak the ref naming rules
in the future, for example to forbid shell metacharacters like '`'
and '"', without putting people in a state that is hard to get out of.
So allow "branch --list" to show these refs and allow "branch -d/-D"
and "update-ref -d" to delete them. Other commands (for example to
rename refs) will continue to not handle these refs but can be changed
in later patches.
Details:
In resolving functions, refuse to resolve refs that don't pass the
git-check-ref-format(1) check unless the new RESOLVE_REF_ALLOW_BAD_NAME
flag is passed. Even with RESOLVE_REF_ALLOW_BAD_NAME, refuse to
resolve refs that escape the refs/ directory and do not match the
pattern [A-Z_]* (think "HEAD" and "MERGE_HEAD").
In locking functions, refuse to act on badly named refs unless they
are being deleted and either are in the refs/ directory or match [A-Z_]*.
Just like other invalid refs, flag resolved, badly named refs with the
REF_ISBROKEN flag, treat them as resolving to null_sha1, and skip them
in all iteration functions except for for_each_rawref.
Flag badly named refs (but not symrefs pointing to badly named refs)
with a REF_BAD_NAME flag to make it easier for future callers to
notice and handle them specially. For example, in a later patch
for-each-ref will use this flag to detect refs whose names can confuse
callers parsing for-each-ref output.
In the transaction API, refuse to create or update badly named refs,
but allow deleting them (unless they try to escape refs/ and don't match
[A-Z_]*).
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin/branch.c | 9 +--
cache.h | 17 +++++-
refs.c | 148 ++++++++++++++++++++++++++++++++++++++----------
refs.h | 12 +++-
t/t1430-bad-ref-name.sh | 125 +++++++++++++++++++++++++++++++++++++++-
5 files changed, 273 insertions(+), 38 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0c7aac0..7e113d6 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -238,7 +238,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
name = mkpathdup(fmt, bname.buf);
target = resolve_ref_unsafe(name,
RESOLVE_REF_READING
- | RESOLVE_REF_NO_RECURSE,
+ | RESOLVE_REF_NO_RECURSE
+ | RESOLVE_REF_ALLOW_BAD_NAME,
sha1, &flags);
if (!target) {
error(remote_branch
@@ -248,7 +249,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
continue;
}
- if (!(flags & REF_ISSYMREF) &&
+ if (!(flags & (REF_ISSYMREF|REF_ISBROKEN)) &&
check_branch_commit(bname.buf, name, sha1, head_rev, kinds,
force)) {
ret = 1;
@@ -268,8 +269,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
? _("Deleted remote branch %s (was %s).\n")
: _("Deleted branch %s (was %s).\n"),
bname.buf,
- (flags & REF_ISSYMREF)
- ? target
+ (flags & REF_ISBROKEN) ? "broken"
+ : (flags & REF_ISSYMREF) ? target
: find_unique_abbrev(sha1, DEFAULT_ABBREV));
}
delete_branch_config(bname.buf);
diff --git a/cache.h b/cache.h
index b735f3f..0501f7d 100644
--- a/cache.h
+++ b/cache.h
@@ -981,16 +981,29 @@ extern int read_ref(const char *refname, unsigned char *sha1);
* If flags is non-NULL, set the value that it points to the
* combination of REF_ISPACKED (if the reference was found among the
* packed references), REF_ISSYMREF (if the initial reference was a
- * symbolic reference) and REF_ISBROKEN (if the ref is malformed).
+ * symbolic reference), REF_BAD_NAME (if the reference name is ill
+ * formed --- see RESOLVE_REF_ALLOW_BAD_NAME below), and REF_ISBROKEN
+ * (if the ref is malformed or has a bad name). See refs.h for more detail
+ * on each flag.
*
* If ref is not a properly-formatted, normalized reference, return
* NULL. If more than MAXDEPTH recursive symbolic lookups are needed,
* give up and return NULL.
*
- * errno is set to something meaningful on error.
+ * RESOLVE_REF_ALLOW_BAD_NAME allows resolving refs even when their
+ * name is invalid according to git-check-ref-format(1). If the name
+ * is bad then the value stored in sha1 will be null_sha1 and the two
+ * flags REF_ISBROKEN and REF_BAD_NAME will be set.
+ *
+ * Even with RESOLVE_REF_ALLOW_BAD_NAME, names that escape the refs/
+ * directory and do not consist of all caps and underscores cannot be
+ * resolved. The function returns NULL for such ref names.
+ * Caps and underscores refers to the special refs, such as HEAD,
+ * FETCH_HEAD and friends, that all live outside of the refs/ directory.
*/
#define RESOLVE_REF_READING 0x01
#define RESOLVE_REF_NO_RECURSE 0x02
+#define RESOLVE_REF_ALLOW_BAD_NAME 0x04
extern const char *resolve_ref_unsafe(const char *ref, int resolve_flags, unsigned char *sha1, int *flags);
extern char *resolve_refdup(const char *ref, int resolve_flags, unsigned char *sha1, int *flags);
diff --git a/refs.c b/refs.c
index fe1352a..e7000f2 100644
--- a/refs.c
+++ b/refs.c
@@ -187,8 +187,8 @@ struct ref_dir {
/*
* Bit values for ref_entry::flag. REF_ISSYMREF=0x01,
- * REF_ISPACKED=0x02, and REF_ISBROKEN=0x04 are public values; see
- * refs.h.
+ * REF_ISPACKED=0x02, REF_ISBROKEN=0x04 and REF_BAD_NAME=0x08 are
+ * public values; see refs.h.
*/
/*
@@ -196,16 +196,16 @@ struct ref_dir {
* the correct peeled value for the reference, which might be
* null_sha1 if the reference is not a tag or if it is broken.
*/
-#define REF_KNOWS_PEELED 0x08
+#define REF_KNOWS_PEELED 0x10
/* ref_entry represents a directory of references */
-#define REF_DIR 0x10
+#define REF_DIR 0x20
/*
* Entry has not yet been read from disk (used only for REF_DIR
* entries representing loose references)
*/
-#define REF_INCOMPLETE 0x20
+#define REF_INCOMPLETE 0x40
/*
* A ref_entry represents either a reference or a "subdirectory" of
@@ -274,6 +274,39 @@ static struct ref_dir *get_ref_dir(struct ref_entry *entry)
return dir;
}
+/*
+ * Check if a refname is safe.
+ * For refs that start with "refs/" we consider it safe as long they do
+ * not try to resolve to outside of refs/.
+ *
+ * For all other refs we only consider them safe iff they only contain
+ * upper case characters and '_' (like "HEAD" AND "MERGE_HEAD", and not like
+ * "config").
+ */
+static int refname_is_safe(const char *refname)
+{
+ if (starts_with(refname, "refs/")) {
+ char *buf;
+ int result;
+
+ buf = xmalloc(strlen(refname) + 1);
+ /*
+ * Does the refname try to escape refs/?
+ * For example: refs/foo/../bar is safe but refs/foo/../../bar
+ * is not.
+ */
+ result = !normalize_path_copy(buf, refname + strlen("refs/"));
+ free(buf);
+ return result;
+ }
+ while (*refname) {
+ if (!isupper(*refname) && *refname != '_')
+ return 0;
+ refname++;
+ }
+ return 1;
+}
+
static struct ref_entry *create_ref_entry(const char *refname,
const unsigned char *sha1, int flag,
int check_name)
@@ -284,6 +317,8 @@ static struct ref_entry *create_ref_entry(const char *refname,
if (check_name &&
check_refname_format(refname, REFNAME_ALLOW_ONELEVEL))
die("Reference has invalid format: '%s'", refname);
+ if (!check_name && !refname_is_safe(refname))
+ die("Reference has invalid name: '%s'", refname);
len = strlen(refname) + 1;
ref = xmalloc(sizeof(struct ref_entry) + len);
hashcpy(ref->u.value.sha1, sha1);
@@ -1111,7 +1146,13 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
refname = parse_ref_line(refline, sha1);
if (refname) {
- last = create_ref_entry(refname, sha1, REF_ISPACKED, 1);
+ int flag = REF_ISPACKED;
+
+ if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ hashclr(sha1);
+ flag |= REF_BAD_NAME | REF_ISBROKEN;
+ }
+ last = create_ref_entry(refname, sha1, flag, 0);
if (peeled == PEELED_FULLY ||
(peeled == PEELED_TAGS && starts_with(refname, "refs/tags/")))
last->flag |= REF_KNOWS_PEELED;
@@ -1249,8 +1290,13 @@ static void read_loose_refs(const char *dirname, struct ref_dir *dir)
hashclr(sha1);
flag |= REF_ISBROKEN;
}
+ if (check_refname_format(refname.buf,
+ REFNAME_ALLOW_ONELEVEL)) {
+ hashclr(sha1);
+ flag |= REF_BAD_NAME | REF_ISBROKEN;
+ }
add_entry_to_dir(dir,
- create_ref_entry(refname.buf, sha1, flag, 1));
+ create_ref_entry(refname.buf, sha1, flag, 0));
}
strbuf_setlen(&refname, dirnamelen);
}
@@ -1369,10 +1415,10 @@ static struct ref_entry *get_packed_ref(const char *refname)
* A loose ref file doesn't exist; check for a packed ref. The
* options are forwarded from resolve_safe_unsafe().
*/
-static const char *handle_missing_loose_ref(const char *refname,
- int resolve_flags,
- unsigned char *sha1,
- int *flags)
+static int resolve_missing_loose_ref(const char *refname,
+ int resolve_flags,
+ unsigned char *sha1,
+ int *flags)
{
struct ref_entry *entry;
@@ -1385,14 +1431,15 @@ static const char *handle_missing_loose_ref(const char *refname,
hashcpy(sha1, entry->u.value.sha1);
if (flags)
*flags |= REF_ISPACKED;
- return refname;
+ return 0;
}
/* The reference is not a packed reference, either. */
if (resolve_flags & RESOLVE_REF_READING) {
- return NULL;
+ errno = ENOENT;
+ return -1;
} else {
hashclr(sha1);
- return refname;
+ return 0;
}
}
@@ -1403,13 +1450,29 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
ssize_t len;
char buffer[256];
static char refname_buffer[256];
+ int bad_name = 0;
if (flags)
*flags = 0;
if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
- errno = EINVAL;
- return NULL;
+ if (flags)
+ *flags |= REF_BAD_NAME;
+
+ if (!(resolve_flags & RESOLVE_REF_ALLOW_BAD_NAME) ||
+ !refname_is_safe(refname)) {
+ errno = EINVAL;
+ return NULL;
+ }
+ /*
+ * dwim_ref() uses REF_ISBROKEN to distinguish between
+ * missing refs and refs that were present but invalid,
+ * to complain about the latter to stderr.
+ *
+ * We don't know whether the ref exists, so don't set
+ * REF_ISBROKEN yet.
+ */
+ bad_name = 1;
}
for (;;) {
char path[PATH_MAX];
@@ -1435,11 +1498,17 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
*/
stat_ref:
if (lstat(path, &st) < 0) {
- if (errno == ENOENT)
- return handle_missing_loose_ref(refname,
- resolve_flags, sha1, flags);
- else
+ if (errno != ENOENT)
return NULL;
+ if (resolve_missing_loose_ref(refname, resolve_flags,
+ sha1, flags))
+ return NULL;
+ if (bad_name) {
+ hashclr(sha1);
+ if (flags)
+ *flags |= REF_ISBROKEN;
+ }
+ return refname;
}
/* Follow "normalized" - ie "refs/.." symlinks by hand */
@@ -1512,6 +1581,11 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
errno = EINVAL;
return NULL;
}
+ if (bad_name) {
+ hashclr(sha1);
+ if (flags)
+ *flags |= REF_ISBROKEN;
+ }
return refname;
}
if (flags)
@@ -1527,8 +1601,13 @@ const char *resolve_ref_unsafe(const char *refname, int resolve_flags, unsigned
if (check_refname_format(buf, REFNAME_ALLOW_ONELEVEL)) {
if (flags)
*flags |= REF_ISBROKEN;
- errno = EINVAL;
- return NULL;
+
+ if (!(resolve_flags & RESOLVE_REF_ALLOW_BAD_NAME) ||
+ !refname_is_safe(buf)) {
+ errno = EINVAL;
+ return NULL;
+ }
+ bad_name = 1;
}
}
}
@@ -2160,18 +2239,16 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname,
int missing = 0;
int attempts_remaining = 3;
- if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
- errno = EINVAL;
- return NULL;
- }
-
lock = xcalloc(1, sizeof(struct ref_lock));
lock->lock_fd = -1;
if (mustexist)
resolve_flags |= RESOLVE_REF_READING;
- if (flags & REF_NODEREF && flags & REF_DELETING)
- resolve_flags |= RESOLVE_REF_NO_RECURSE;
+ if (flags & REF_DELETING) {
+ resolve_flags |= RESOLVE_REF_ALLOW_BAD_NAME;
+ if (flags & REF_NODEREF)
+ resolve_flags |= RESOLVE_REF_NO_RECURSE;
+ }
refname = resolve_ref_unsafe(refname, resolve_flags,
lock->old_sha1, &type);
@@ -3519,6 +3596,13 @@ int ref_transaction_update(struct ref_transaction *transaction,
if (have_old && !old_sha1)
die("BUG: have_old is true but old_sha1 is NULL");
+ if (!is_null_sha1(new_sha1) &&
+ check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ strbuf_addf(err, "refusing to update ref with bad name %s",
+ refname);
+ return -1;
+ }
+
update = add_update(transaction, refname);
hashcpy(update->new_sha1, new_sha1);
update->flags = flags;
@@ -3544,6 +3628,12 @@ int ref_transaction_create(struct ref_transaction *transaction,
if (!new_sha1 || is_null_sha1(new_sha1))
die("BUG: create ref with null new_sha1");
+ if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
+ strbuf_addf(err, "refusing to create ref with bad name %s",
+ refname);
+ return -1;
+ }
+
update = add_update(transaction, refname);
hashcpy(update->new_sha1, new_sha1);
diff --git a/refs.h b/refs.h
index c61b8f4..2bc3556 100644
--- a/refs.h
+++ b/refs.h
@@ -56,12 +56,20 @@ struct ref_transaction;
/*
* Reference cannot be resolved to an object name: dangling symbolic
- * reference (directly or indirectly), corrupt reference file, or
- * symbolic reference refers to ill-formatted reference name.
+ * reference (directly or indirectly), corrupt reference file,
+ * reference exists but name is bad, or symbolic reference refers to
+ * ill-formatted reference name.
*/
#define REF_ISBROKEN 0x04
/*
+ * Reference name is not well formed.
+ *
+ * See git-check-ref-format(1) for the definition of well formed ref names.
+ */
+#define REF_BAD_NAME 0x08
+
+/*
* The signature for the callback function for the for_each_*()
* functions below. The memory pointed to by the refname and sha1
* arguments is only guaranteed to be valid for the duration of a
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index c7b19b0..468e856 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@ -4,7 +4,8 @@ test_description='Test handling of ref names that check-ref-format rejects'
. ./test-lib.sh
test_expect_success setup '
- test_commit one
+ test_commit one &&
+ test_commit two
'
test_expect_success 'fast-import: fail on invalid branch name ".badbranchname"' '
@@ -37,6 +38,107 @@ test_expect_success 'fast-import: fail on invalid branch name "bad[branch]name"'
test_must_fail git fast-import <input
'
+test_expect_success 'git branch shows badly named ref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch >output &&
+ grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -d can delete badly named ref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -d broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -D can delete badly named ref' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -D broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -D cannot delete non-ref in .git dir' '
+ echo precious >.git/my-private-file &&
+ echo precious >expect &&
+ test_must_fail git branch -D ../../my-private-file &&
+ test_cmp expect .git/my-private-file
+'
+
+test_expect_success 'branch -D cannot delete absolute path' '
+ git branch -f extra &&
+ test_must_fail git branch -D "$(pwd)/.git/refs/heads/extra" &&
+ test_cmp_rev HEAD extra
+'
+
+test_expect_success 'git branch cannot create a badly named ref' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ test_must_fail git branch broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'branch -m cannot rename to a bad ref name' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ test_might_fail git branch -D goodref &&
+ git branch goodref &&
+ test_must_fail git branch -m goodref broken...ref &&
+ test_cmp_rev master goodref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_failure 'branch -m can rename from a bad ref name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch -m broken...ref renamed &&
+ test_cmp_rev master renamed &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'push cannot create a badly named ref' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ test_must_fail git push "file://$(pwd)" HEAD:refs/heads/broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_failure 'push --mirror can delete badly named ref' '
+ top=$(pwd) &&
+ git init src &&
+ git init dest &&
+
+ (
+ cd src &&
+ test_commit one
+ ) &&
+ (
+ cd dest &&
+ test_commit two &&
+ git checkout --detach &&
+ cp .git/refs/heads/master .git/refs/heads/broken...ref
+ ) &&
+ git -C src push --mirror "file://$top/dest" &&
+ git -C dest branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'rev-parse skips symref pointing to broken name' '
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git branch shadow one &&
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ git symbolic-ref refs/tags/shadow refs/heads/broken...ref &&
+
+ git rev-parse --verify one >expect &&
+ git rev-parse --verify shadow >actual 2>err &&
+ test_cmp expect actual &&
+ test_i18ngrep "ignoring.*refs/tags/shadow" err
+'
+
test_expect_success 'update-ref --no-deref -d can delete reference to broken name' '
git symbolic-ref refs/heads/badname refs/heads/broken...ref &&
test_when_finished "rm -f .git/refs/heads/badname" &&
@@ -45,6 +147,27 @@ test_expect_success 'update-ref --no-deref -d can delete reference to broken nam
test_path_is_missing .git/refs/heads/badname
'
+test_expect_success 'update-ref -d can delete broken name' '
+ cp .git/refs/heads/master .git/refs/heads/broken...ref &&
+ test_when_finished "rm -f .git/refs/heads/broken...ref" &&
+ git update-ref -d refs/heads/broken...ref &&
+ git branch >output &&
+ ! grep -e "broken\.\.\.ref" output
+'
+
+test_expect_success 'update-ref -d cannot delete non-ref in .git dir' '
+ echo precious >.git/my-private-file &&
+ echo precious >expect &&
+ test_must_fail git update-ref -d my-private-file &&
+ test_cmp expect .git/my-private-file
+'
+
+test_expect_success 'update-ref -d cannot delete absolute path' '
+ git branch -f extra &&
+ test_must_fail git update-ref -d "$(pwd)/.git/refs/heads/extra" &&
+ test_cmp_rev HEAD extra
+'
+
test_expect_success 'update-ref --stdin fails create with bad ref name' '
echo "create ~a refs/heads/master" >stdin &&
test_must_fail git update-ref --stdin <stdin 2>err &&
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related [relevance 5%]
* Re: Aborting 'rebase main feat' removes unversioned files
2021-09-05 7:43 4% ` Ævar Arnfjörð Bjarmason
@ 2021-09-08 0:40 5% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2021-09-08 0:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jeff King, Fedor Biryukov, Bagas Sanjaya, Git Mailing List
On Sun, Sep 5, 2021 at 12:44 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Sat, Sep 04 2021, Elijah Newren wrote:
>
> > On Sat, Sep 4, 2021 at 3:19 AM Jeff King <peff@peff.net> wrote:
> >>
> >> On Sat, Sep 04, 2021 at 11:51:19AM +0200, Fedor Biryukov wrote:
> >>
> >> > There is no way this could be the intended behavior, but the good news
> >> > is that I cannot reproduce it...
> >> > Looks like it occurs only in one git version (2.31.0.windows.1, IIRC).
> >> > And it does not occur in the latest git version: git version 2.33.0.windows.2.
> >>
> >> I think it is a bug, and it seems to reproduce easily for me (with both
> >> the current tip of master, and with v2.33.0). Here's the recipe you
> >> showed, with a little debugging at the end:
> >>
> >> set -x
> >> git init repo
> >> cd repo
> >> git commit -m base --allow-empty
> >> git checkout -b feat
> >> echo feat >readme.txt
> >> git add readme.txt
> >> git commit -m txt=feat
> >> git checkout main
> >> echo precious >readme.txt
> >>
> >> cat readme.txt
> >> git checkout feat
> >> cat readme.txt
> >> git rebase main feat
> >> cat readme.txt
> >>
> >> This produces:
> >>
> >> + cat readme.txt
> >> precious
> >> + git checkout feat
> >> error: The following untracked working tree files would be overwritten by checkout:
> >> readme.txt
> >> Please move or remove them before you switch branches.
> >> Aborting
> >> + cat readme.txt
> >> precious
> >> + git rebase main feat
> >> Current branch feat is up to date.
> >> + cat readme.txt
> >> feat
> >>
> >> So git-checkout was not willing to overwrite the untracked content, but
> >> rebase was happy to obliterate it.
> >>
> >> It does the right thing in very old versions. Bisecting, it looks like
> >> the problem arrived in 5541bd5b8f (rebase: default to using the builtin
> >> rebase, 2018-08-08). So the bug is in the conversion from the legacy
> >> shell script to C (which makes sense; the shell version was just calling
> >> "git checkout", which we know does the right thing).
> >>
> >> -Peff
> >
> > Turns out this is quite a mess. It's also related to the "don't
> > remove empty working directories" discussion we had earlier this
> > week[1], because we assumed all relevant codepaths correctly avoided
> > deleting untracked files and directories in the way. But they don't.
> > And rebase isn't the only offender, because this is buried in
> > unpack_trees. In fact, it traces back to (and before)
> > fcc387db9b ("read-tree -m -u: do not overwrite or remove untracked
> > working tree files.", 2006-05-17)
> > which has additional commentary over at
> > https://lore.kernel.org/git/7v8xp1jc9h.fsf_-_@assigned-by-dhcp.cox.net/.
> > It appears that before this time, git happily nuked untracked files
> > and considered them expendable, in basically all cases. However, this
> > patch continued considering them as expendable whenever opts->reset
> > was true. There wasn't much comment about it at the time for the
> > reasoning of how opts->reset was handled, though trying to read
> > between the lines perhaps Junio was trying to limit the backward
> > compatibility concerns of introducing new errors to fewer code paths?
> > Anyway, Junio did mention `read-tree --reset` explicitly, but this
> > opts->reset usage also occurs in am, checkout, reset -- and anything
> > that calls the reset_head() function including: rebase, stash,
> > sequencer.c, and add-patch.c.
> >
> > So, then...should we preserve untracked (and non-ignored) files in all
> > these cases? This rebase case seems clear, but others might be less
> > clear. For example, should "git reset --hard" nuke untracked files
> > (what if it's a directory of untracked files getting nuked just to
> > place a single file in the location of the directory)? The
> > documentation isn't explicit, but after reading it I would assume that
> > untracked files should be preserved. Since we've had bugs in "git
> > reset --hard" before, such as requiring two invocations in order to
> > clear out unmerged entries (see [2] and [3]), that also suggests that
> > this is just another bug in the same area. But the bug has been
> > around so long that people might be expecting it; our testsuite has
> > several cases that incidentally do. Granted, it's better to throw an
> > error and require explicit extra steps than to nuke potentially
> > important work, but some folks might be unhappy with a change here.
> > Similarly with "git checkout -f".
> >
> > And stash.c, which operates in that edge case area has tests with
> > files nuked from the cache without nuking it from the working tree
> > (causing the working tree file to be considered untracked), and then
> > attempts to have multiple tests operate on that kind of case. Those
> > cases look a bit buggy to me for other reasons (I'm still digging),
> > but those bugs are kind of hidden by the untracked file nuking bugs,
> > so fixing the latter requires fixing the former. And stash.c is a
> > mess of shelling out to subcommands. Ick.
> >
> > I have some partial patches, but don't know if I'll have anything to
> > post until I figure out the stash mess...
>
> I'd just like to applaud this effort, and also suggest that the most
> useful result of any such findings would be for us to produce some new
> test in t/ showing these various cases of nuking/clobbering and other
> "non-precious" edge cases in this logic. See[1] and its linked [2] for
> references to some of the past discussions around these cases.
Yeah, I discovered the problems by making some testcases for the
avoid-removing-current-working-directory case, and then when I was
surprised by some behaviors I saw I started adding tests for the
(mistaken?) nuking of untracked files...and then saw this bug report.
While I've also been trying to add fixes for the issues I've found,
making the testcases (trying to figure out which commands had bugs and
how to trigger them) was definitely the hardest part of the effort so
far, and likely the most valuable.
> 1. https://lore.kernel.org/git/87a6q9kacx.fsf@evledraar.gmail.com/
> 2. https://lore.kernel.org/git/87ftsi68ke.fsf@evledraar.gmail.com/
The first item, preserving ignored files, is related but different (I
was specifically discussing non-ignored untracked files above).
However on the topic of precious ignored files...both checkout and
merge have a --[no-]overwriite-ignore flag to select this behavior.
Unfortunately, the merge command only passes that flag along to the
fast-forwarding code path and ignores it for all other merge backends.
But merge-ort could trivially be made to handle it (search for the
line of code that reads "if (1/* FIXME: opts->overwrite_ignore*/)" and
note opts->overwrite_ignore isn't a flag that exists, yet), and then
it'd just need to be threaded through merge/rebase/cherry-pick/revert
toplevel commands down to that line of code. Also, my preliminary
patches touch on the ignore handling for other codepaths and make it
clear how one could support such a flag for those other cases; I'll
leave some comments in the cover letter when I submit it. Anyway, if
we were to get those other codepaths all hooked up, perhaps we could
add a core.overwrite_ignored option defaulting to true and giving
people a place to just configure this once. I would much rather a
global option than attempting to provide another class of file that
users have to configure (ignored but precious), especially as we have
had plenty of bugs and problems just dealing with the two classes of
'untracked' and 'ignored' already.
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
@ 2018-11-12 16:07 5% ` Duy Nguyen
2018-11-12 9:49 4% ` Ævar Arnfjörð Bjarmason
1 sibling, 0 replies; 200+ results
From: Duy Nguyen @ 2018-11-12 16:07 UTC (permalink / raw)
To: git
Cc: per.lundberg, Ævar Arnfjörð Bjarmason,
Git Mailing List, jost, Joshua Jensen, Junio C Hamano,
Clemens Buchacher, Holger Hellmuth (IKS), Kevin Ballard
On Mon, Nov 12, 2018 at 10:09 AM Matthieu Moy <git@matthieu-moy.fr> wrote:
> May I remind an idea I sugested in an old thread: add an intermediate level
> where ignored files to be overwritten are renamed (eg. foo -> foo~ like Emacs'
> backup files):
>
> https://public-inbox.org/git/vpqd3t9656k.fsf@bauges.imag.fr/
>
> One advantage of the "rename" behavior is that it's safer that the current,
> but still not very disturbing for people who like the current behavior. This
> makes it a good candidate for a default behavior.
I have something else in the bag that does something like this. The
idea is that we go ahead and do destructive things but we let the user
undo.
Some more background in [1] but basically we hash "every" change and
store in the object database (in this case we store "foo" content
before overwriting it). We maintain a list of these hashes so that
undo is possible, but of course we don't keep infinite change history,
eventually too old changes will be pruned. [1] talks about index
changes (e.g. "git add -p") but it could apply to worktree changes as
well (and I'm also eyeing $GIT_DIR/config changes).
The upside: a similar undo mechanism that works for more than just
this case and it allows undoing multiple times while foo~ only allow
once. The downside: hashing is definitely heavier than renaming foo to
foo~. So this will feature be opt-in in most cases. But for
"dangerous" overwrite like this case, I think we value the file
content more and make it opt-out.
[1] https://public-inbox.org/git/CACsJy8A3QCYY6QeJQYkbCKYh=7Q7pj=rer_OQHLGoAMqTNomNA@mail.gmail.com/
--
Duy
^ permalink raw reply [relevance 5%]
* Hyper links of london sale occurs in several designs
@ 2013-02-07 6:34 5% deishei001
0 siblings, 0 replies; 200+ results
From: deishei001 @ 2013-02-07 6:34 UTC (permalink / raw)
To: git
The actual style cues tend to be obtained from numerous designs that were a
sizable accomplishment after which blend in to that one piece of incredible
vintage jewellery. Hyper <strong> links of london sale
<http://www.cheapcheaplinksoflondonbracelets.co.uk/> </strong> occurs in
several designs as well as styles because of its huge number of customers.
They've numerous colours as well as designs way too. Therefore apart from
becoming the evidence of companionship, they are able to cause you to
research excellent as well as fashionable. You should use these phones
personalize your own seems. You may also existing these phones your own
buddy, sweetheart, sweetheart, child, boy along with other people. This
really is some thing which would pull a person interest. The actual style
cues tend to be from numerous styles that have been the uniform after which
it blend in to that certain piece of amazing vintage jewellery. This kind of
jewellery includes titanium, precious metal (10 in order to fourteen karat),
surgery metal, as well as niobium is really suggested. The very best element
regarding niobium in addition to titanium is actually these people never
have the response using the chemical substance make-up of our own personal
pores and skin. Nevertheless, surgery metal usually have a slight volume of
nickel however it does not result in a good hypersensitivity. These types of
alloys are often consequently utilized seeing that hypoallergenic jewellery
layer. Platinum eagle as well is produce this sort of jewellery.
Additionally with this, real copper, free of nickel or even nickel
additional alloys, is really a hypoallergenic things with regard to
jewellery.
The actual jewellery number of <strong> links of london friendship bracelet
<http://www.cheapcheaplinksoflondonbracelets.co.uk/> </strong> is actually
remarkable and could complement any kind of modern jewellery shop from any
location. Probably the most desired jewellery included in this may be the
Back links operating out of birmingham Companionship Bracelets. This is
often a wonderful method to help to make brand new buddies or even continue
aged companionship. Among the rest of the number of jewelries the actual
companionship music group is definitely an unique item. It’s awesome as well
as fashionable along with a touch of style as well as guarantee. It's
targeted mostly from teens as well as youngsters obtainable who wish to keep
a signal associated with companionship together. Companionship bracelet
perform behave as the driver within reviving your own companionship. The
actual Hyperlinks operating out of <strong> links of london bracelets
<http://www.cheapcheaplinksoflondonbracelets.co.uk/> </strong> will come in
just about all sizes and shapes, with regard to each man as well as woman.
They're fashionable as well as smooth, supplying personal design claims.
Miniatures from the accurate bracelet will also be accessible right now.
Each and every bracelets occurs within appreciation colors as well as
dimensions to complement a person. To distinguish a few of the couple of
companionship bracelet tend to be small young man, small woman, azure, metal
salt precious metal as well as gray companionship bracelet, darkish
yellow-colored fluoric, darkish lemon, graduation crimson, pewter whitened,
patriotic companionship bracelet and so on.
They've distinctive colours as well as designs as well. Therefore apart from
as being a evidence of companionship, they are able to lead you to appear
awesome as well as fashionable. You need to use these to personalize your
own appears. You may also present these to your own pal, sweetheart,
sweetheart, child, boy while others. Miniatures from the real bracelet will
also be available now. Pretty much every bracelets will come in appreciation
colours as well as dimensions to complement a person. To name a few of the
handful of companionship bracelet tend to be small young man, small woman,
azure, metal salt precious metal as well as off white companionship
bracelet, darkish yellow-colored fluoric, darkish lemon, graduation crimson,
pewter whitened, patriotic <strong> cheap links of london bracelets
<http://www.cheapcheaplinksoflondonbracelets.co.uk/> </strong> and so
forth. Hyperlinks operating out of birmingham Companionship Bracelets is
available in several styles as well as styles because of its wide selection
of purchasers.
http://www.cheapcheaplinksoflondonbracelets.co.uk/
--
View this message in context: http://git.661346.n2.nabble.com/Hyper-links-of-london-sale-occurs-in-several-designs-tp7577205.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply [relevance 5%]
* Re: what should "git clean -n -f [-d] [-x] <pattern>" do?
@ 2024-01-27 10:00 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-01-27 10:00 UTC (permalink / raw)
To: Sergey Organov; +Cc: Elijah Newren, git
Sergey Organov <sorganov@gmail.com> writes:
> I'm still arguing in favor of fixing "-n", and I believe a fix is needed
> independently from decision about "-f -f".
Even though I do not personally like it, I do not think "which
between do-it (f) and do-not-do-it (n) do you want to use?" is
broken. It sometimes irritates me to find "git clean" (without "-f"
or "-n", and with clean.requireForce not disabled) complain, and I
personally think "git clean" when clean.requireForce is in effect
and no "-n" or "-f" were given should pretend as if "-n" were given.
I wish if it were "without -n or -f, we pretend as if -n were given,
possibly with a warning that says 'you need -f if you actually want
to carry out these operations'".
But that is a separate usability issue.
What I find broken is that giving one 'f' and one 'n' in different
order, i.e. "-f -n" and "-n -f", does not do what I expect. If you
are choosing between do-it (f) and do-not-do-it (n), you ought to be
able to rely on the usual last-one-wins rule. That I find broken.
The mistake[*] of "-f -f" is rather obvious, given that the other
"normal" ways to tweak what is affected by the command are done as
"what else do we clean? directories (d)? ignored (x)?..." options.
When we add the upcoming "precious" bit support, we should make sure
that the way to trigger "oh, by the way, please clobber those paths
that are marked precious, too" is not by giving three '-f'. It
would make it impossible to ask for that without also removing
nested repositories, which takes two '-f'.
[Footnote]
* To a lessor extent, the -v (verbose) option shares the same
problem as "-f -f" here, in that its worldview is to assume that
a single "verbosity level" is sufficient. Unlike the severity
level thing, however, the user who wanted to see only messages
about X but have to also see messages about Y and Z that are at
the same or lessor verbosity level as X can filter out unwanted
messages without causing a real harm.
^ permalink raw reply [relevance 5%]
* Re: PATCH: improve git switch documentation
@ 2021-07-10 20:49 5% ` Felipe Contreras
0 siblings, 0 replies; 200+ results
From: Felipe Contreras @ 2021-07-10 20:49 UTC (permalink / raw)
To: Martin, Felipe Contreras, Sergey Organov; +Cc: Junio C Hamano, git
Martin wrote:
> On 10/07/2021 21:45, Felipe Contreras wrote:
> > Martin wrote:
> > No. You can add all the explanation you want after "Resets the branch to
> > <head>.", but most of that explanation would be redundant, because as we
> > already agreed, there's no way to reset the head of a branch without
> > changing the branch.
>
> By that logic a lot of explanations are redundant, because on some
> lever, if every user thinks far enough lots of things can be concluded.
Yes. And that's what a good writer aims for: to minimize the number of
words needed for the vast majority of readers to understand the point.
The more work you as a writer put into a sentence, the less work
hundreds or thousands of readers have to do while reading that sentence.
Rendundancy is only good when you are trying to reach a certain
word count for a university essay.
> From the docs (and similar on git checkout)
> > --force
> >
> > An alias for --discard-changes.
> > --discard-changes
> >
> > Proceed even if the index or the working tree differs from HEAD.
> > Both the index and working tree are restored to match the switching
> > target. If --recurse-submodules is specified, submodule content is
> > also restored to match the switching target. This is used to throw
> > away local changes.
There's no adjective I can use for the official git documentation that
isn't crass, so let's just say that I find it extremelly lacking.
That paragraph above is a great example: it's a) hard to read, b)
unecessarily verbose, c) is wrongly ordered, d) redundant, and e) not
even correct.
> If the working tree is made to match the target, then it can not retain
> local changes. That can be concluded.
> Yet, it is explicitly mentioned.
>
> Does it really hurt to mention it?
Yes it does.
Time is the most precious resource we all have. We should not waste the
most precious resource of our readers.
Throw away local changes.
That does a much better job.
If you want to be more explicit, you can add a bit more information:
Throw away local changes either in the staging area or the working
tree.
Why does the user have to know what HEAD is? And why does it matter that
the staging area is held in a file called "index"?
The current explanation is just bad.
But as I said, if you want to replicate the current style of the
documentation, go ahead, but it would be pretty much a bloated version
of "resets the branch to <head>".
> But anyway.
> I brought forward my idea. I explained my reasoning.
> If it (this part) is downvoted/rejected then that it how it is.
It's not a matter of consensus. There are proposals where literally
everyone is in favor, and yet they are never merged.
There's only one person you need to convince.
So, what I suggest you to do is take into consideration all we have
discussed and send another patch, because that's ultimately all that
matters. Moreover, it usually happens to me that while I write the patch
is when finally the previously-discussed ideas start to click.
> >>>> So, I still ask:
> >>>> - If "--force" to overwrite the work tree can clearly state that change
> >>>> to files will be "thrown away".
> >>>> - Then why can "force" re-using an existing branch name not do the same?
> >>>
> >>> Because we would be forcing two things now.
> >>
> >> Which 2 things?
> >>
> >> The worktree overwriting is *not* forced by -C
> >>
> >> git switch -C b1 b2
> >> git checkout -B b1 b2
> >>
> >> both give an error if the worktree has changed files.
> >>
> >> This is only about what happens to the branch.
> >>
> >> I.e we force the branchname to point to our new branch.
> >> And that means the branchname no longe points to the old branch, and the
> >> old branch therefore is removed.
> >
> > It seems your proposal is to make `git switch -c --force b1 b2` be the same as
> > `git switch -C b1 b2`, but that would also make it the same as
> > `git switch -C --force b1 b2`. Therefore it would be forcing two things.
> >
> > Or is your proposal something else?
> >
>
> No. I definitely want to keep those 2 apart from each other.
>
> For each force-needing action, you should have to specify it's own force
> flag.
OK, but I don't see the concrete proposal. What would be the flag that
makes -c "forceful"?
Cheers.
--
Felipe Contreras
^ permalink raw reply [relevance 5%]
* Re: Fetching everything in another bare repo
@ 2023-03-09 15:35 5% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2023-03-09 15:35 UTC (permalink / raw)
To: Paul Smith; +Cc: git
On Thu, Mar 09, 2023 at 08:55:27AM -0500, Paul Smith wrote:
> > OK. It's not clear to me if this archive repo retains the old
> > references, or if it simply has a bunch of unreachable objects.
> > That distinction will matter below.
>
> Sorry; I've been using Git for a long time but am still not totally
> immersed in the terminology :).
>
> Basically, these bare clones have "gc.pruneExpire=never" set, and have
> never had any GC operations run so all commits are still present (when
> you say "unreachable" I assume you mean, not reachable through any
> reference).
Right, that's what I mean by unreachable. And no, you didn't use any
terminology wrong. I was just not sure if you realized that running
"fetch" would not get the unreachable objects. :)
> There is a separate database of information containing SHAs for these
> commits, that is used to find them, but there is nothing in Git itself
> that references them so they are indeed unreachable as far as Git is
> concerned.
OK, that makes sense (and I've done something like that before, as
well).
> Oh interesting. I did a quick verification and all of the objects /
> packfiles in the old clone either don't exist in the new one, or are
> identical. I'm sure you expected that but I needed to reassure myself
> I wouldn't be overwriting anything :).
The files are named after the sha1 of their contents (and that goes for
both loose objects and packfiles). But certainly it's a good idea to
double check that nothing funny is going on.
> One question: is the objects/info/packs file anything to be concerned
> about or will git repack (or something) take care of handling it?
You can ignore it. It will be regenerated by git-repack. But also, it's
pretty useless these days. It's only used for "dumb" fetches (e.g., when
you export a repo via static http, but without using the git-aware CGI).
> > And then you can do any ref updates in the new repository (since it
> > now has all objects from both).
>
> It's actually possible that I don't care about refs at all. I might
> only care about objects. I'm not sure, I can check what exists in the
> old clone.
Yeah, if you have a separate database of branch tips, etc, then the refs
aren't necessary. As long as you are careful not to run "gc" or repack
without "-k".
You may want to try the "preciousObjects" repository extension, which
was designed to prevent accidents for a case like this. Something like:
[this will cause old versions of Git that don't understand
extensions.* to bail on all commands for safety]
$ git config core.repositoryformatversion 1
[this will tell old versions of Git that don't understand this
particular extension to bail on all commands for safety. But more
importantly, it will tell recent versions (> 2.6.3) to allow most
commands, but not ones that would delete unreachable objects]
$ git config extensions.preciousObjects true
[this is it in action]
$ git repack -ad
fatal: cannot delete packs in a precious-objects repo
$ git prune
fatal: cannot prune in a precious-objects repo
Sadly it's not quite smart enough to realize that "git repack -adk" is
safe. If you want to occasionally repack with that, you'd have to
manually disable the flag for a moment.
I will also say that while I implemented this extension a while back, it
never actually saw production use for my intended case. So I think it's
pretty good (and certainly safer than nothing), but it's not thoroughly
tested in the wild.
-Peff
^ permalink raw reply [relevance 5%]
* [PATCH 3/5] t6036, t6042: prefer test_path_is_file, test_path_is_missing
@ 2018-05-24 7:04 5% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2018-05-24 7:04 UTC (permalink / raw)
To: git; +Cc: gitster, Elijah Newren
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t/t6036-recursive-corner-cases.sh | 4 +--
t/t6042-merge-rename-corner-cases.sh | 40 ++++++++++++++--------------
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 3e659cff28..b716155723 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -488,7 +488,7 @@ test_expect_success 'merge of D & E2 fails but has appropriate contents' '
test $(git rev-parse :1:a/file) = $(git rev-parse C:a/file) &&
test $(git rev-parse :0:ignore-me) = $(git rev-parse A:ignore-me) &&
- test -f a~HEAD
+ test_path_is_file a~HEAD
)
'
@@ -512,7 +512,7 @@ test_expect_success 'merge of E2 & D fails but has appropriate contents' '
test $(git rev-parse :1:a/file) = $(git rev-parse C:a/file) &&
test $(git rev-parse :0:ignore-me) = $(git rev-parse A:ignore-me) &&
- test -f a~D^0
+ test_path_is_file a~D^0
)
'
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
index b76da8fcdf..90225b8bcd 100755
--- a/t/t6042-merge-rename-corner-cases.sh
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -38,7 +38,7 @@ test_expect_success "Does git preserve Gollum's precious artifact?" '
test_must_fail git merge -s recursive rename-the-ring &&
# Make sure git did not delete an untracked file
- test -f ring
+ test_path_is_file ring
)
'
@@ -213,8 +213,8 @@ test_expect_failure 'detect rename/add-source and preserve all data' '
git ls-files -o >out &&
test_line_count = 1 out &&
- test -f a &&
- test -f b &&
+ test_path_is_file a &&
+ test_path_is_file b &&
test $(git rev-parse HEAD:b) = $(git rev-parse A:a) &&
test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
@@ -236,8 +236,8 @@ test_expect_failure 'detect rename/add-source and preserve all data, merge other
git ls-files -o >out &&
test_line_count = 1 out &&
- test -f a &&
- test -f b &&
+ test_path_is_file a &&
+ test_path_is_file b &&
test $(git rev-parse HEAD:b) = $(git rev-parse A:a) &&
test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
@@ -302,8 +302,8 @@ test_expect_success 'rename/directory conflict + clean content merge' '
test $(git rev-parse :2:newfile) = $(git hash-object expect) &&
- test -f newfile/realfile &&
- test -f newfile~HEAD
+ test_path_is_file newfile/realfile &&
+ test_path_is_file newfile~HEAD
)
'
@@ -340,8 +340,8 @@ test_expect_success 'rename/directory conflict + content merge conflict' '
test $(git rev-parse :2:newfile) = $(git rev-parse left-conflict:newfile) &&
test $(git rev-parse :3:newfile) = $(git rev-parse right:file) &&
- test -f newfile/realfile &&
- test -f newfile~HEAD
+ test_path_is_file newfile/realfile &&
+ test_path_is_file newfile~HEAD
)
'
@@ -394,7 +394,7 @@ test_expect_success 'disappearing dir in rename/directory conflict handled' '
echo 7 >>expect &&
test_cmp expect sub &&
- test -f sub
+ test_path_is_file sub
)
'
@@ -453,10 +453,10 @@ test_expect_success 'handle rename/rename (2to1) conflict correctly' '
git ls-files -o >out &&
test_line_count = 3 out &&
- test ! -f a &&
- test ! -f b &&
- test -f c~HEAD &&
- test -f c~C^0 &&
+ test_path_is_missing a &&
+ test_path_is_missing b &&
+ test_path_is_file c~HEAD &&
+ test_path_is_file c~C^0 &&
test $(git hash-object c~HEAD) = $(git rev-parse C:a) &&
test $(git hash-object c~C^0) = $(git rev-parse B:b)
@@ -509,7 +509,7 @@ test_expect_success 'merge has correct working tree contents' '
test $(git rev-parse :3:b) = $(git rev-parse A:a) &&
test $(git rev-parse :2:c) = $(git rev-parse A:a) &&
- test ! -f a &&
+ test_path_is_missing a &&
test $(git hash-object b) = $(git rev-parse A:a) &&
test $(git hash-object c) = $(git rev-parse A:a)
)
@@ -562,9 +562,9 @@ test_expect_failure 'detect conflict with rename/rename(1to2)/add-source merge'
test $(git rev-parse 2:b) = $(git rev-parse B:b) &&
test $(git rev-parse 3:c) = $(git rev-parse C:c) &&
- test -f a &&
- test -f b &&
- test -f c
+ test_path_is_file a &&
+ test_path_is_file b &&
+ test_path_is_file c
)
'
@@ -664,8 +664,8 @@ test_expect_success 'rename/rename/add-dest merge still knows about conflicting
test $(git hash-object b~HEAD) = $(git rev-parse C:b) &&
test $(git hash-object b~B\^0) = $(git rev-parse B:b) &&
- test ! -f b &&
- test ! -f c
+ test_path_is_missing b &&
+ test_path_is_missing c
)
'
--
2.17.0.1.gda85003413
^ permalink raw reply related [relevance 5%]
* Re: mergetool: what to do about deleting precious files?
2017-05-30 0:52 5% ` Junio C Hamano
@ 2017-05-30 23:04 5% ` Philip Oakley
2017-05-31 0:02 5% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Philip Oakley @ 2017-05-30 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
From: "Junio C Hamano" <gitster@pobox.com>
Thanks for the replies. Let's see if I've got it...
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> If I now understand correctly, the merge process flow is:
>>
>> * canonicalise content (eol, smudge-clean, $id, renormalise, etc)
>> * diff the content (internal, or GIT_EXTERNAL_DIFF)
>> * apply the diff
>> * if conflicts, only then use merge-driver/tool
>>
>> Would that be a correct interpretation?
>
> Not quite. There are a lot more going on before any of those steps:
>
> * Find the common ancestor commit (which could be many).
IIUC Git selects one of them, rather than all if there are many (which then
may not be the optimum)
>
> * Walk the three trees (the common ancestor's, ours and theirs) in
> parallel, noticing what happened to each path. Depending on what
> happened to the path in each branch, the merge may or may not
> "conflict" (e.g. when both sides added exactly the same contents
> to the same path, they are not counted as conflicting. when we
> removed while they modified, they show as conflicting).
I'm assuming here that this is the sha-oid comparison, and then checking the
tree/blob names that match them. (the top tree not having a name). So here
"conflict free" is that the sha-oids match.
Also, I thnk this is saying that added or removed trees or blobs are in some
sense are 'conflict free' (though still subject to rename/move detection
etc). An added file/blob would be conflict free for merging into it's tree,
yes?
IIUC, the comparison is therefore using the in-repo sha-oids;
unless --renormalise was given which will do a smudge-clean washing cycle
and recomute fresh canonical sha-oids for the comparison (rather than doing
it later).
>
> * For paths that are conflicting, feed the canonicalized content of
> the versions from common, ours and theirs to the file-level merge
> driver.
So this is where any .gitattibutes settings come in, or is the merge driver
after the diff step? (which could also be a user diff?)
> The builtin file-level merge driver takes two xdiff (one
> between ancestor and ours, the other between ancestore and
> theirs) and reconciles them to produce the result. But that is
> irrelevant in the context of "custom merge driver"; the builtin
> one is skipped altogether and the custom contents merge driver
> the user specified via the attributes is used instead.
>
> Notice that the second step above has no customization knobs. Any
> path the second step deems not to conflict is "merged cleanly"
> without even triggering the "oops, ours and theirs did conflicting
> changes, to the content; let's see how the final content should look
> like" (aka the third step). This is *not* because "Git knows the
> best"; it is merely that nobody felt the need for a mechanism to
> allow customizing the second step.
>
> And that is why I said you need a new customization mechanism if you
> want to affect the outcome of the scenario that started this thread.
Ok, I think I can see how I was confused between the "tree merge" (oid
conflict detection) and the more usual (to users) "file merge" (line by
line, etc.). I wasn't sure where to find that as someone relatively new to
Git.
Thanks for the explanations.
--
Philip
---
This email has been checked for viruses by AVG.
http://www.avg.com
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Add extra logic required to detect endianness on Solaris
@ 2014-05-01 18:58 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2014-05-01 18:58 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
Charles Bailey <cbailey32@bloomberg.net> writes:
> #if !defined(__BYTE_ORDER)
> +/* Known to be needed on Solaris but designed to potentially more portable */
> +
> +#if !defined(__BIG_ENDIAN)
> +#define __BIG_ENDIAN 4321
> +#endif
> +
> +#if !defined(__LITTLE_ENDIAN)
> +#define __LITTLE_ENDIAN 1234
> +#endif
> +
> +#if defined(_BIG_ENDIAN)
> +#define __BYTE_ORDER __BIG_ENDIAN
> +#endif
> +#if defined(_LITTLE_ENDIAN)
> +#define __BYTE_ORDER __LITTLE_ENDIAN
> +#endif
The existing support is only for platforms where all three macros
(BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN) are defined, and the
convention used on such platforms where BYTE_ORDER is set to either
one of the *_ENDIAN macros to tell the code which byte order we
have. This mimics the convention where __BYTE_ORDER and other two
macros are already defined with two leading underscores, and in such
a case we do not have to do anything. We make the final decision to
use or bypass bswap64() in our ntohll() implementation based on the
variables with double leading underscores.
This patch seems to address two unrelated issues in that.
(1) The existing support does not help a platform where the
convention is to define either _BIG_ENDIAN (with one leading
underscore) or _LITTLE_ENDIAN and not both, which is Solaris
but there may be others.
(2) There may be __LITTLE_ENDIAN and __BIG_ENDIAN macros already
defined on the platform. Or these may not have been defined at
all. You avoid unconditionally redefing these.
I find the latter iffy.
What is the reason for avoiding redefinition? Is it because you
know the original values they have are precious? And if so in what
way they are precious? If the reason of avoiding redefinition is
because you do not even know what their values are (so that you are
trying to be safe by preserving), what other things can you say
about their values you are preserving?
Specifically, do you know that these two are defined differently, so
that defining __BYTE_ORDER to one of them and comparing it to
__BIG_ENDIAN is a good way to tell if the platform is big endian?
I would understand it if (2) were "we undefine if these are defined
and then define them as 4321 and 1234 respectively, in order to
avoid a compiler warning against redefinition of a macro", but that
is not what I am seeing, so I am not sure what you meant to achieve
by that "if !defined()" constructs.
Thanks.
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
@ 2018-11-28 6:54 5% ` Per Lundberg
0 siblings, 0 replies; 200+ results
From: Per Lundberg @ 2018-11-28 6:54 UTC (permalink / raw)
To: brian m. carlson
Cc: Jacob Keller, Duy Nguyen, Ævar Arnfjörð Bjarmason,
Git mailing list, Junio C Hamano
On 11/28/18 3:21 AM, brian m. carlson wrote:
Thanks for the elaboration, Brian - good to get things down to a
practical, real-world level.
> [...]
>
> I point this out to underscore how fundamental this change is. People
> overwhelmingly do not read the release notes, so expecting people to
> realize that a change has been made, especially when many people only
> upgrade Git because of a security issue, may result in unexpected
> consequences.
This is one of the more important things of software engineering. _Don't
mix security fixes with breaking changes_. They are very different
things and like you say, we can't really expect people to real release
notes for every little incremental release we do.
That's an important part of the SemVer guarantee: a minor version
bump/patch level increase means "bug fix" or "added functionality in a
backwards-compatible way". So: no changing of default behavior or
semantics, but adding a new behavior which is opt-in is perfectly fine.
> Just because we don't think of this use of Git as normal or desirable > doesn't mean people don't do it and don't expect it to keep working.
In other words, we need to be "bug-by-bug" compatible with previous
versions. :-) What some people would consider a bug, others would
consider a feature.
> I think any change we make here has to be opt-in, at least until Git
> 3.0. A config knob would probably be the right way to go.
Agree. It's less than optimal but I think it's something that we all
could live with. Deciding to switching the default (or not) is then
rightfully postponed to a later time, and we can revisit the pros and
cons then. The important thing now is to get the functionality
implemented in a good way, tested and eventually merged.
--
Per Lundberg
^ permalink raw reply [relevance 5%]
* [PATCH v2] l10n: de.po: translate 68 new messages
@ 2015-12-25 19:38 5% ` Ralf Thielow
0 siblings, 0 replies; 200+ results
From: Ralf Thielow @ 2015-12-25 19:38 UTC (permalink / raw)
To: phillip.szelat
Cc: git, tr, jk, stimming, matthias.ruester, magnus.goerlitz,
Ralf Thielow
Translate 68 new messages came from git.pot update in
f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and
2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
2015-12-25 20:13 GMT+01:00 Phillip Sz <phillip.szelat@gmail.com>:
> Hi,
>
> Just some comments, the rest looks fine.
Thanks for review, Phillip! Merry Christmas to you, too.
Here's v2.
po/de.po | 190 ++++++++++++++++++++++++++++-----------------------------------
1 file changed, 84 insertions(+), 106 deletions(-)
diff --git a/po/de.po b/po/de.po
index 1ce4193..2324605 100644
--- a/po/de.po
+++ b/po/de.po
@@ -32,17 +32,16 @@ msgstr ""
"und zu committen."
#: advice.c:101 builtin/merge.c:1225
msgid "You have not concluded your merge (MERGE_HEAD exists)."
msgstr "Sie haben Ihren Merge nicht abgeschlossen (MERGE_HEAD existiert)."
#: advice.c:103
-#, fuzzy
msgid "Please, commit your changes before merging."
-msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie den Merge ausführen."
+msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie mergen."
#: advice.c:104
msgid "Exiting because of unfinished merge."
msgstr "Beende wegen nicht abgeschlossenem Merge."
#: archive.c:12
msgid "git archive [<options>] <tree-ish> [<path>...]"
@@ -1110,54 +1109,54 @@ msgstr "Konnte Referenzen nicht entfernen: %s"
#, c-format
msgid "could not remove reference %s"
msgstr "Konnte Referenz %s nicht löschen"
#: ref-filter.c:245
#, c-format
msgid "format: %%(end) atom used without corresponding atom"
-msgstr ""
+msgstr "format: %%(end) Atom ohne zugehöriges Atom verwendet"
#: ref-filter.c:704
#, c-format
msgid "positive value expected contents:lines=%s"
-msgstr ""
+msgstr "Positiver Wert erwartet contents:lines=%s"
#: ref-filter.c:833
#, c-format
msgid "expected format: %%(color:<color>)"
-msgstr ""
+msgstr "Erwartetes Format: %%(color:<Farbe>)"
#: ref-filter.c:835
msgid "unable to parse format"
msgstr "Konnte Format nicht parsen."
#: ref-filter.c:870
#, c-format
msgid "expected format: %%(align:<width>,<position>)"
-msgstr ""
+msgstr "Erwartetes Format: %%(align:<Breite>,<Position>)"
#: ref-filter.c:893
#, c-format
msgid "improper format entered align:%s"
-msgstr ""
+msgstr "Sie haben ein ungültiges Format eingegeben align:%s"
#: ref-filter.c:898
#, c-format
msgid "positive width expected with the %%(align) atom"
-msgstr ""
+msgstr "Positive Breitenangabe für %%(align) erwartet"
#: ref-filter.c:1219
#, c-format
msgid "malformed object at '%s'"
msgstr "fehlerhaftes Objekt bei '%s'"
#: ref-filter.c:1561
#, c-format
msgid "format: %%(end) atom missing"
-msgstr ""
+msgstr "Format: %%(end) Atom fehlt"
#: ref-filter.c:1615
#, c-format
msgid "malformed object name %s"
msgstr "Missgebildeter Objektname %s"
#: remote.c:756
@@ -2632,22 +2631,20 @@ msgstr ""
#: builtin/am.c:2220
#, c-format
msgid "Invalid value for --patch-format: %s"
msgstr "Ungültiger Wert für --patch-format: %s"
#: builtin/am.c:2253
-#, fuzzy
msgid "git am [<options>] [(<mbox>|<Maildir>)...]"
-msgstr "git am [Optionen] [(<mbox>|<E-Mail-Verzeichnis>)...]"
+msgstr "git am [<Optionen>] [(<mbox>|<E-Mail-Verzeichnis>)...]"
#: builtin/am.c:2254
-#, fuzzy
msgid "git am [<options>] (--continue | --skip | --abort)"
-msgstr "git am [Optionen] (--continue | --skip | --abort)"
+msgstr "git am [<Optionen>] (--continue | --skip | --abort)"
#: builtin/am.c:2260
msgid "run interactively"
msgstr "interaktiv ausführen"
#: builtin/am.c:2262
msgid "historical option -- no-op"
@@ -3476,17 +3473,16 @@ msgid "git branch [<options>] [-r] (-d | -D) <branch-name>..."
msgstr "git branch [<Optionen>] [-r] (-d | -D) <Branchname>..."
#: builtin/branch.c:28
msgid "git branch [<options>] (-m | -M) [<old-branch>] <new-branch>"
msgstr "git branch [<Optionen>] (-m | -M) [<alter-Branch>] <neuer-Branch>"
#: builtin/branch.c:29
-#, fuzzy
msgid "git branch [<options>] [-r | -a] [--points-at]"
-msgstr "git branch [<Optionen>] [-r | -a] [--merged | --no-merged]"
+msgstr "git branch [<Optionen>] [-r | -a] [--points-at]"
#: builtin/branch.c:142
#, c-format
msgid ""
"deleting branch '%s' that has been merged to\n"
" '%s', but not yet merged to HEAD."
msgstr ""
@@ -3738,22 +3734,20 @@ msgid "edit the description for the branch"
msgstr "die Beschreibung für den Branch bearbeiten"
#: builtin/branch.c:644
msgid "force creation, move/rename, deletion"
msgstr "Erstellung, Verschiebung/Umbenennung oder Löschung erzwingen"
#: builtin/branch.c:645
-#, fuzzy
msgid "print only branches that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Branches ausgeben"
#: builtin/branch.c:646
-#, fuzzy
msgid "print only branches that are not merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur nicht zusammengeführte Branches ausgeben"
#: builtin/branch.c:647
msgid "list branches in columns"
msgstr "Branches in Spalten auflisten"
#: builtin/branch.c:648 builtin/for-each-ref.c:38 builtin/tag.c:366
msgid "key"
@@ -3766,17 +3760,16 @@ msgstr "sortiere nach diesem Feld"
#: builtin/branch.c:651 builtin/for-each-ref.c:41 builtin/notes.c:398
#: builtin/notes.c:401 builtin/notes.c:561 builtin/notes.c:564
#: builtin/tag.c:369
msgid "object"
msgstr "Objekt"
#: builtin/branch.c:652
-#, fuzzy
msgid "print only branches of the object"
-msgstr "nur Tags von dem Objekt ausgeben"
+msgstr "nur Branches von diesem Objekt ausgeben"
#: builtin/branch.c:670
msgid "Failed to resolve HEAD as a valid ref."
msgstr "Konnte HEAD nicht als gültige Referenz auflösen."
#: builtin/branch.c:674 builtin/clone.c:697
msgid "HEAD not found below refs/heads!"
@@ -3908,19 +3901,16 @@ msgid ""
"git cat-file (-t [--allow-unknown-type]|-s [--allow-unknown-type]|-e|-p|"
"<type>|--textconv) <object>"
msgstr ""
"git cat-file (-t [--allow-unknown-type]|-s [--allow-unknown-type]|-e|-p|"
"<Art>|--textconv) <Objekt>"
#: builtin/cat-file.c:429
-#, fuzzy
msgid "git cat-file (--batch | --batch-check) [--follow-symlinks]"
-msgstr ""
-"git cat-file (--batch | --batch-check) [--follow-symlinks] < <Liste-von-"
-"Objekten"
+msgstr "git cat-file (--batch | --batch-check) [--follow-symlinks]"
#: builtin/cat-file.c:466
msgid "<type> can be one of: blob, tree, commit, tag"
msgstr "<Art> kann sein: blob, tree, commit, tag"
#: builtin/cat-file.c:467
msgid "show object type"
@@ -3972,18 +3962,16 @@ msgid "show all objects with --batch or --batch-check"
msgstr "alle Objekte mit --batch oder --batch-check anzeigen"
#: builtin/check-attr.c:11
msgid "git check-attr [-a | --all | <attr>...] [--] <pathname>..."
msgstr "git check-attr [-a | --all | <Attribut>...] [--] <Pfadname>..."
#: builtin/check-attr.c:12
-#, fuzzy
msgid "git check-attr --stdin [-z] [-a | --all | <attr>...]"
-msgstr ""
-"git check-attr --stdin [-z] [-a | --all | <Attribut>...] < <Liste-von-Pfaden>"
+msgstr "git check-attr --stdin [-z] [-a | --all | <Attribut>...]"
#: builtin/check-attr.c:19
msgid "report all attributes set on file"
msgstr "alle Attribute einer Datei ausgeben"
#: builtin/check-attr.c:20
msgid "use .gitattributes only from the index"
@@ -4697,17 +4685,18 @@ msgid "key=value"
msgstr "Schlüssel=Wert"
#: builtin/clone.c:94
msgid "set config inside the new repository"
msgstr "Konfiguration innerhalb des neuen Repositories setzen"
#: builtin/clone.c:300
-#, fuzzy, c-format
+#, c-format
msgid "reference repository '%s' as a linked checkout is not supported yet."
-msgstr "Referenziertes Repository '%s' ist kein lokales Repository."
+msgstr "Referenziertes Repository '%s' wird noch nicht als verknüpftes\n"
+"Arbeitsverzeichnis unterstützt."
#: builtin/clone.c:302
#, c-format
msgid "reference repository '%s' is not a local repository."
msgstr "Referenziertes Repository '%s' ist kein lokales Repository."
#: builtin/clone.c:307
@@ -6228,27 +6217,24 @@ msgid "file to read from"
msgstr "Datei zum Einlesen"
#: builtin/for-each-ref.c:9
msgid "git for-each-ref [<options>] [<pattern>]"
msgstr "git for-each-ref [<Optionen>] [<Muster>]"
#: builtin/for-each-ref.c:10
-#, fuzzy
msgid "git for-each-ref [--points-at <object>]"
-msgstr "git for-each-ref [<Optionen>] [<Muster>]"
+msgstr "git for-each-ref [--points-at <Objekt>]"
#: builtin/for-each-ref.c:11
-#, fuzzy
msgid "git for-each-ref [(--merged | --no-merged) [<object>]]"
-msgstr "git branch [<Optionen>] [-r | -a] [--merged | --no-merged]"
+msgstr "git for-each-ref [(--merged | --no-merged) [<Objekt>]]"
#: builtin/for-each-ref.c:12
-#, fuzzy
msgid "git for-each-ref [--contains [<object>]]"
-msgstr "git for-each-ref [<Optionen>] [<Muster>]"
+msgstr "git for-each-ref [--contains [<Objekt>]]"
#: builtin/for-each-ref.c:27
msgid "quote placeholders suitably for shells"
msgstr "Platzhalter als Shell-String formatieren"
#: builtin/for-each-ref.c:29
msgid "quote placeholders suitably for perl"
@@ -6267,32 +6253,28 @@ msgid "show only <n> matched refs"
msgstr "nur <n> passende Referenzen anzeigen"
#: builtin/for-each-ref.c:37 builtin/tag.c:372
msgid "format to use for the output"
msgstr "für die Ausgabe zu verwendendes Format"
#: builtin/for-each-ref.c:41
-#, fuzzy
msgid "print only refs which points at the given object"
-msgstr "nur Tags von dem Objekt ausgeben"
+msgstr "nur auf dieses Objekt zeigende Referenzen ausgeben"
#: builtin/for-each-ref.c:43
-#, fuzzy
msgid "print only refs that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Referenzen ausgeben"
#: builtin/for-each-ref.c:44
-#, fuzzy
msgid "print only refs that are not merged"
-msgstr "nur Branches ausgeben, die nicht zusammengeführt sind"
+msgstr "nur nicht zusammengeführte Referenzen ausgeben"
#: builtin/for-each-ref.c:45
-#, fuzzy
msgid "print only refs which contain the commit"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur Referenzen ausgeben, die diesen Commit enthalten"
#: builtin/fsck.c:156 builtin/prune.c:140
msgid "Checking connectivity"
msgstr "Prüfe Konnektivität"
#: builtin/fsck.c:486
msgid "Checking object directories"
@@ -6369,14 +6351,20 @@ msgstr "zu langes Objekt-Verzeichnis %.*s"
msgid ""
"The last gc run reported the following. Please correct the root cause\n"
"and remove %s.\n"
"Automatic cleanup will not be performed until the file is removed.\n"
"\n"
"%s"
msgstr ""
+"Die letzte Ausführung von \"gc run\" enthielt die folgenden Meldungen.\n"
+"Bitte beheben Sie das Hauptproblem und löschen Sie %s.\n"
+"Ein automatischer Cleanup wird nicht ausgeführt, bis diese Datei entfernt\n"
+"wurde.\n"
+"\n"
+"%s"
#: builtin/gc.c:327
msgid "prune unreferenced objects"
msgstr "unreferenzierte Objekte entfernen"
#: builtin/gc.c:329
msgid "be more thorough (increased runtime)"
@@ -6664,17 +6652,16 @@ msgid ""
"git hash-object [-t <type>] [-w] [--path=<file> | --no-filters] [--stdin] "
"[--] <file>..."
msgstr ""
"git hash-object [-t <Art>] [-w] [--path=<Datei> | --no-filters] [--stdin] "
"[--] <Datei>..."
#: builtin/hash-object.c:81
-#, fuzzy
msgid "git hash-object --stdin-paths"
-msgstr "git hash-object --stdin-paths < <Liste-von-Pfaden>"
+msgstr "git hash-object --stdin-paths"
#: builtin/hash-object.c:92
msgid "type"
msgstr "Art"
#: builtin/hash-object.c:92
msgid "object type"
@@ -7397,15 +7384,15 @@ msgstr "[PATCH] nicht entfernen/hinzufügen"
#: builtin/log.c:1239
msgid "don't output binary diffs"
msgstr "keine binären Unterschiede ausgeben"
#: builtin/log.c:1241
msgid "output all-zero hash in From header"
-msgstr ""
+msgstr "Hash mit Nullen in \"From\"-Header ausgeben"
#: builtin/log.c:1243
msgid "don't include a patch matching a commit upstream"
msgstr ""
"keine Patches einschließen, die einem Commit im Upstream-Branch entsprechen"
#: builtin/log.c:1245
@@ -8825,20 +8812,18 @@ msgid "report pruned objects"
msgstr "gelöschte Objekte melden"
#: builtin/prune.c:109 builtin/worktree.c:127
msgid "expire objects older than <time>"
msgstr "Objekte älter als <Zeit> verfallen lassen"
#: builtin/prune.c:123
-#, fuzzy
msgid "cannot prune in a precious-objects repo"
-msgstr "Kann existierendes Objekt %s nicht lesen."
+msgstr "kann \"prune\" in precious-objects Repository nicht ausführen"
#: builtin/pull.c:69
-#, fuzzy
msgid "git pull [<options>] [<repository> [<refspec>...]]"
msgstr "git pull [<Optionen>] [<Repository> [<Refspec>...]]"
#: builtin/pull.c:113
msgid "Options related to merging"
msgstr "Optionen bezogen auf Merge"
@@ -9300,17 +9285,16 @@ msgid "refname>:<expect"
msgstr "Referenzname>:<Erwartungswert"
#: builtin/push.c:548 builtin/send-pack.c:176
msgid "require old value of ref to be at this value"
msgstr "Referenz muss sich auf dem angegebenen Wert befinden"
#: builtin/push.c:550
-#, fuzzy
msgid "check|on-demand|no"
-msgstr "bei-Bedarf"
+msgstr "check|on-demand|no"
#: builtin/push.c:551
msgid "control recursive pushing of submodules"
msgstr "rekursiven \"push\" von Submodulen steuern"
#: builtin/push.c:553 builtin/send-pack.c:169
msgid "use thin pack"
@@ -9477,17 +9461,16 @@ msgstr ""
"git remote [-v | --verbose] update [-p | --prune] [(<Gruppe> | <Remote>)...]"
#: builtin/remote.c:20
msgid "git remote set-branches [--add] <name> <branch>..."
msgstr "git remote set-branches [--add] <Name> <Branch>..."
#: builtin/remote.c:21 builtin/remote.c:70
-#, fuzzy
msgid "git remote get-url [--push] [--all] <name>"
-msgstr "git remote set-url [--push] <Name> <neueURL> [<alteURL>]"
+msgstr "git remote get-url [--push] [--all] <Name>"
#: builtin/remote.c:22 builtin/remote.c:75
msgid "git remote set-url [--push] <name> <newurl> [<oldurl>]"
msgstr "git remote set-url [--push] <Name> <neueURL> [<alteURL>]"
#: builtin/remote.c:23 builtin/remote.c:76
msgid "git remote set-url --add <name> <newurl>"
@@ -9903,24 +9886,24 @@ msgstr "Branch hinzufügen"
#: builtin/remote.c:1468
msgid "no remote specified"
msgstr "kein Remote-Repository angegeben"
#: builtin/remote.c:1485
msgid "query push URLs rather than fetch URLs"
-msgstr ""
+msgstr "nur URLs für Push ausgeben"
#: builtin/remote.c:1487
msgid "return all URLs"
-msgstr ""
+msgstr "alle URLs ausgeben"
#: builtin/remote.c:1515
-#, fuzzy, c-format
+#, c-format
msgid "no URLs configured for remote '%s'"
-msgstr "Kein Upstream-Branch für Branch '%s' konfiguriert."
+msgstr "Keine URLs für Remote-Repository '%s' konfiguriert."
#: builtin/remote.c:1541
msgid "manipulate push URLs"
msgstr "URLs für \"push\" manipulieren"
#: builtin/remote.c:1543
msgid "add URL"
@@ -10022,15 +10005,15 @@ msgstr "maximale Größe für jede Paketdatei"
#: builtin/repack.c:187
msgid "repack objects in packs marked with .keep"
msgstr ""
"Objekte umpacken, die sich in mit .keep markierten Pack-Dateien befinden"
#: builtin/repack.c:197
msgid "cannot delete packs in a precious-objects repo"
-msgstr ""
+msgstr "kann Pack-Dateien in precious-objects Repository nicht löschen"
#: builtin/repack.c:381
#, c-format
msgid "removing '%s' failed"
msgstr "Löschen von '%s' fehlgeschlagen"
#: builtin/replace.c:19
@@ -10628,17 +10611,16 @@ msgid ""
"git show-ref [-q | --quiet] [--verify] [--head] [-d | --dereference] [-s | --"
"hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<pattern>...]"
msgstr ""
"git show-ref [-q | --quiet] [--verify] [--head] [-d | --dereference] [-s | --"
"hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<Muster>...] "
#: builtin/show-ref.c:11
-#, fuzzy
msgid "git show-ref --exclude-existing[=<pattern>]"
-msgstr "git show-ref --exclude-existing[=<Muster>] < <Referenzliste>"
+msgstr "git show-ref --exclude-existing[=<Muster>]"
#: builtin/show-ref.c:165
msgid "only show tags (can be combined with heads)"
msgstr "nur Tags anzeigen (kann mit \"heads\" kombiniert werden)"
#: builtin/show-ref.c:166
msgid "only show heads (can be combined with tags)"
@@ -10670,104 +10652,104 @@ msgstr ""
msgid "show refs from stdin that aren't in local repository"
msgstr ""
"Referenzen von der Standard-Eingabe anzeigen, die sich nicht im lokalen "
"Repository befinden"
#: builtin/stripspace.c:17
msgid "git stripspace [-s | --strip-comments]"
-msgstr ""
+msgstr "git stripspace [-s | --strip-comments]"
#: builtin/stripspace.c:18
msgid "git stripspace [-c | --comment-lines]"
-msgstr ""
+msgstr "git stripspace [-c | --comment-lines]"
#: builtin/stripspace.c:35
msgid "skip and remove all lines starting with comment character"
-msgstr ""
+msgstr "alle Zeilen, die mit dem Kommentarzeichen beginnen, überspringen und "
+"entfernen"
#: builtin/stripspace.c:38
msgid "prepend comment character and blank to each line"
-msgstr ""
+msgstr "Kommentarzeichen mit Leerzeichen an jeder Zeile voranstellen"
#: builtin/submodule--helper.c:79 builtin/submodule--helper.c:167
msgid "alternative anchor for relative paths"
-msgstr ""
+msgstr "Alternativer Anker für relative Pfade"
#: builtin/submodule--helper.c:84
msgid "git submodule--helper list [--prefix=<path>] [<path>...]"
-msgstr ""
+msgstr "git submodule--helper list [--prefix=<Pfad>] [<Pfad>...]"
#: builtin/submodule--helper.c:114
msgid "git submodule--helper name <path>"
-msgstr ""
+msgstr "git submodule--helper name <Pfad>"
#: builtin/submodule--helper.c:120
-#, fuzzy, c-format
+#, c-format
msgid "no submodule mapping found in .gitmodules for path '%s'"
-msgstr "Keine Submodul-Zuordnung in .gitmodules für Pfad '$sm_path' gefunden"
+msgstr "Keine Submodul-Zuordnung in .gitmodules für Pfad '%s' gefunden"
#: builtin/submodule--helper.c:170
msgid "where the new submodule will be cloned to"
-msgstr ""
+msgstr "Pfad für neues Submodul"
#: builtin/submodule--helper.c:173
-#, fuzzy
msgid "name of the new submodule"
-msgstr "Aktualisierung: ignoriert Submodule"
+msgstr "Name des neuen Submoduls"
#: builtin/submodule--helper.c:176
msgid "url where to clone the submodule from"
-msgstr ""
+msgstr "URL von der das Submodul geklont wird"
#: builtin/submodule--helper.c:182
-#, fuzzy
msgid "depth for shallow clones"
-msgstr ""
-"die Historie eines Klons mit unvollständiger Historie (shallow) vertiefen"
+msgstr "Tiefe des Klons mit unvollständiger Historie (shallow)"
#: builtin/submodule--helper.c:188
msgid ""
"git submodule--helper clone [--prefix=<path>] [--quiet] [--reference "
"<repository>] [--name <name>] [--url <url>][--depth <depth>] [--] [<path>...]"
msgstr ""
+"git submodule--helper clone [--prefix=<Pfad>] [--quiet] [--reference "
+"<Repository>] [--name <Name>] [--url <URL>][--depth <Tiefe>] [--] [<Pfad>...]"
#: builtin/submodule--helper.c:202 builtin/submodule--helper.c:208
#: builtin/submodule--helper.c:216
-#, fuzzy, c-format
+#, c-format
msgid "could not create directory '%s'"
msgstr "Konnte Verzeichnis '%s' nicht erstellen."
#: builtin/submodule--helper.c:204
-#, fuzzy, c-format
+#, c-format
msgid "clone of '%s' into submodule path '%s' failed"
-msgstr "Klonen von '$url' in Submodul-Pfad '$sm_path' fehlgeschlagen"
+msgstr "Klonen von '%s' in Submodul-Pfad '%s' fehlgeschlagen"
#: builtin/submodule--helper.c:227
-#, fuzzy, c-format
+#, c-format
msgid "cannot open file '%s'"
-msgstr "Kann Paketdatei '%s' nicht öffnen"
+msgstr "Kann Datei '%s' nicht öffnen"
#: builtin/submodule--helper.c:232
-#, fuzzy, c-format
+#, c-format
msgid "could not close file %s"
-msgstr "Konnte '%s' nicht schließen."
+msgstr "Konnte Datei '%s' nicht schließen."
#: builtin/submodule--helper.c:247
-#, fuzzy, c-format
+#, c-format
msgid "could not get submodule directory for '%s'"
-msgstr "Konnte Verzeichnis '%s' nicht erstellen."
+msgstr "Konnte Submodul-Verzeichnis '%s' nicht finden."
#: builtin/submodule--helper.c:273
msgid "fatal: submodule--helper subcommand must be called with a subcommand"
-msgstr ""
+msgstr "fatal: submodule-helper muss mit einem Unterkommando aufgerufen werden"
#: builtin/submodule--helper.c:280
#, c-format
msgid "fatal: '%s' is not a valid submodule--helper subcommand"
-msgstr ""
+msgstr "fatal: '%s' ist kein gültiges Unterkommando von submodule-helper"
#: builtin/symbolic-ref.c:7
msgid "git symbolic-ref [<options>] <name> [<ref>]"
msgstr "git symbolic-ref [<Optionen>] <Name> [<Referenz>]"
#: builtin/symbolic-ref.c:8
msgid "git symbolic-ref -d [-q] <name>"
@@ -10803,21 +10785,20 @@ msgstr ""
"<Tagname> [<Commit>]"
#: builtin/tag.c:24
msgid "git tag -d <tagname>..."
msgstr "git tag -d <Tagname>..."
#: builtin/tag.c:25
-#, fuzzy
msgid ""
"git tag -l [-n[<num>]] [--contains <commit>] [--points-at <object>]\n"
"\t\t[--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]"
msgstr ""
"git tag -l [-n[<Nummer>]] [--contains <Commit>] [--points-at <Objekt>]\n"
-"\t\t[<Muster>...]"
+"\t\t[--format=<Muster>] [--[no-]merged [<Commit>]] [<Muster>...]"
#: builtin/tag.c:27
msgid "git tag -v <tagname>..."
msgstr "git tag -v <Tagname>..."
#: builtin/tag.c:80
#, c-format
@@ -10945,22 +10926,20 @@ msgid "show tag list in columns"
msgstr "Liste der Tags in Spalten anzeigen"
#: builtin/tag.c:362 builtin/tag.c:363
msgid "print only tags that contain the commit"
msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
#: builtin/tag.c:364
-#, fuzzy
msgid "print only tags that are merged"
-msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
+msgstr "nur Tags ausgeben, die gemerged wurden"
#: builtin/tag.c:365
-#, fuzzy
msgid "print only tags that are not merged"
-msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
+msgstr "nur Tags ausgeben, die nicht gemerged wurden"
#: builtin/tag.c:370
msgid "print only tags of the object"
msgstr "nur Tags von dem Objekt ausgeben"
#: builtin/tag.c:399
msgid "--column and -n are incompatible"
@@ -10975,17 +10954,16 @@ msgid "--contains option is only allowed with -l."
msgstr "--contains Option ist nur erlaubt mit -l."
#: builtin/tag.c:423
msgid "--points-at option is only allowed with -l."
msgstr "--points-at Option ist nur erlaubt mit -l."
#: builtin/tag.c:425
-#, fuzzy
msgid "--merged and --no-merged option are only allowed with -l"
-msgstr "-n Option ist nur erlaubt mit -l."
+msgstr "Die Optionen --merged und --no-merged sind nur mit -l erlaubt."
#: builtin/tag.c:433
msgid "only one -F or -m option is allowed."
msgstr "nur eine -F oder -m Option ist erlaubt."
#: builtin/tag.c:453
msgid "too many params"
@@ -11276,26 +11254,24 @@ msgid "git verify-tag [-v | --verbose] <tag>..."
msgstr "git verify-tag [-v | --verbose] <Tag>..."
#: builtin/verify-tag.c:83
msgid "print tag contents"
msgstr "Tag-Inhalte ausgeben"
#: builtin/worktree.c:15
-#, fuzzy
msgid "git worktree add [<options>] <path> [<branch>]"
-msgstr "git worktree add [<Optionen>] <Pfad> <Branch>"
+msgstr "git worktree add [<Optionen>] <Pfad> [<Branch>]"
#: builtin/worktree.c:16
msgid "git worktree prune [<options>]"
msgstr "git worktree prune [<Optionen>]"
#: builtin/worktree.c:17
-#, fuzzy
msgid "git worktree list [<options>]"
-msgstr "git worktree prune [<Optionen>]"
+msgstr "git worktree list [<Optionen>]"
#: builtin/worktree.c:39
#, c-format
msgid "Removing worktrees/%s: not a valid directory"
msgstr "Lösche worktrees/%s: kein gültiges Verzeichnis"
#: builtin/worktree.c:45
@@ -11692,48 +11668,50 @@ msgstr ""
#: git-bisect.sh:538
msgid "bisect run success"
msgstr "'bisect run' erfolgreich ausgeführt"
#: git-bisect.sh:565
msgid "please use two different terms"
-msgstr ""
+msgstr "Bitte verwenden Sie zwei verschiedene Begriffe."
#: git-bisect.sh:575
-#, fuzzy, sh-format
+#, sh-format
msgid "'$term' is not a valid term"
-msgstr "'%s' ist kein gültiger Zeitstempel"
+msgstr "'$term' ist kein gültiger Begriff"
#: git-bisect.sh:578
#, sh-format
msgid "can't use the builtin command '$term' as a term"
-msgstr ""
+msgstr "Kann eingebautes Kommando '$term' nicht als Begriff verwenden"
#: git-bisect.sh:587 git-bisect.sh:593
#, sh-format
msgid "can't change the meaning of term '$term'"
-msgstr ""
+msgstr "Kann Bedeutung von '$term' nicht ändern."
#: git-bisect.sh:606
#, sh-format
msgid "Invalid command: you're currently in a $TERM_BAD/$TERM_GOOD bisect."
msgstr ""
"Ungültiges Kommando: Sie sind gerade bei einer binären $TERM_BAD/$TERM_GOOD "
"Suche."
#: git-bisect.sh:636
msgid "no terms defined"
-msgstr ""
+msgstr "Keine Begriffe definiert."
#: git-bisect.sh:653
#, sh-format
msgid ""
"invalid argument $arg for 'git bisect terms'.\n"
"Supported options are: --term-good|--term-old and --term-bad|--term-new."
msgstr ""
+"Ungültiges Argument $arg für 'git bisect terms'.\n"
+"Unterstützte Optionen sind: --term-good|--term-old und --term-bad|--term-new."
#: git-rebase.sh:57
msgid ""
"When you have resolved this problem, run \"git rebase --continue\".\n"
"If you prefer to skip this patch, run \"git rebase --skip\" instead.\n"
"To check out the original branch and stop rebasing, run \"git rebase --abort"
"\"."
--
2.7.0.rc2.212.g788e337
^ permalink raw reply related [relevance 5%]
* Re: [PATCH 1/1] Introduce "precious" file concept
@ 2019-02-20 9:41 5% ` Duy Nguyen
2019-02-20 9:36 5% ` Steffen Jost
1 sibling, 0 replies; 200+ results
From: Duy Nguyen @ 2019-02-20 9:41 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, Git Mailing List, Per Lundberg, Steffen Jost,
Joshua Jensen, Matthieu Moy, Clemens Buchacher, Holger Hellmuth,
Kevin Ballard
On Wed, Feb 20, 2019 at 4:19 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> > I personally do not believe in "backup log"; if we can screw up and
> > can fail to stop an operation that must avoid losing info, then we
> > can screw up the same way and fail to design and implement "backup"
> > to save info before an operation loses it.
>
> Yes, there could be some unforseen interaction between git commands
> where we should have such a backup log, but did not think to implement
> it. I'd hope such cases would be reported, and we could fix them.
>
> But those sorts of cases aren't why we started discussing this, rather
> we *know* what the data shredding command interaction is, but there
> wasn't a consensus for just not shredding data by default by making
> users use "checkout -f" or "merge -f" to proceed. I.e. taking some
> variant of my "trashable" patch[1].
>
> > If we do a good job in
> > supporting "precious" in various operations, we can rely less on
> > "backup log" and still be safe ;-)
>
> Is noted in previous discussions[2] I think that's entirely
> implausible. I think at best the "precious" facility will be used to
> mark e.g *.o files as "don't check in, but don't clean (Makefile handles
> it)".
>
> Most git users are at the level of only knowing very basic
> add/commit/pull/push command interaction. I feel strongly that we need
> to make our tools safe to use by default, and not require some
> relatively advanced "precious"/attribute facility to be carefully
> configured in advance so we don't throw away uncommitted work on the
> likes of merge/checkout.
There is a trade off somewhere. "new user first" should not come at
the cost for more experienced users.
Making "git checkout/merge" abort while it's working before breaks
scripts. And requiring to mark trashable files manually duplicates a
lot of ignore patterns. Have a look at any .gitignore file, the
majority of them is for discardable files because "ignored" class was
created with those in mind (*.o and friends). So now you would need to
add more or less the same set of ignore rules in .gitattributes to
mark them trashable, and gitignore/gitattributes rules are not exactly
compatible, you can't just blindly copy them over. Every time you add
one more .gitignore rule, there's a good chance you need to add a
similar rule for trashable attribute.
Maybe we just add a new "newbie" config knob and turn on the safety
nets on. Leave the knob on by default. And I will turn it off in my
~/.gitconfig as soon as it's real.
--
Duy
^ permalink raw reply [relevance 5%]
* [PATCH v3] l10n: de.po: translate 68 new messages
2015-12-22 17:39 5% [PATCH] l10n: de.po: translate 68 new messages Ralf Thielow
@ 2015-12-29 18:18 5% ` Ralf Thielow
0 siblings, 0 replies; 200+ results
From: Ralf Thielow @ 2015-12-29 18:18 UTC (permalink / raw)
To: matthias.ruester
Cc: git, tr, jk, stimming, phillip.szelat, magnus.goerlitz,
Ralf Thielow
Translate 68 new messages came from git.pot update in
f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and
2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Matthias Rüster <matthias.ruester@gmail.com>
---
po/de.po | 190 ++++++++++++++++++++++++++++-----------------------------------
1 file changed, 84 insertions(+), 106 deletions(-)
diff --git a/po/de.po b/po/de.po
index 1ce4193..8c5f05d 100644
--- a/po/de.po
+++ b/po/de.po
@@ -32,17 +32,16 @@ msgstr ""
"und zu committen."
#: advice.c:101 builtin/merge.c:1225
msgid "You have not concluded your merge (MERGE_HEAD exists)."
msgstr "Sie haben Ihren Merge nicht abgeschlossen (MERGE_HEAD existiert)."
#: advice.c:103
-#, fuzzy
msgid "Please, commit your changes before merging."
-msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie den Merge ausführen."
+msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie mergen."
#: advice.c:104
msgid "Exiting because of unfinished merge."
msgstr "Beende wegen nicht abgeschlossenem Merge."
#: archive.c:12
msgid "git archive [<options>] <tree-ish> [<path>...]"
@@ -1110,54 +1109,54 @@ msgstr "Konnte Referenzen nicht entfernen: %s"
#, c-format
msgid "could not remove reference %s"
msgstr "Konnte Referenz %s nicht löschen"
#: ref-filter.c:245
#, c-format
msgid "format: %%(end) atom used without corresponding atom"
-msgstr ""
+msgstr "Format: %%(end) Atom ohne zugehöriges Atom verwendet"
#: ref-filter.c:704
#, c-format
msgid "positive value expected contents:lines=%s"
-msgstr ""
+msgstr "Positiver Wert erwartet contents:lines=%s"
#: ref-filter.c:833
#, c-format
msgid "expected format: %%(color:<color>)"
-msgstr ""
+msgstr "Erwartetes Format: %%(color:<Farbe>)"
#: ref-filter.c:835
msgid "unable to parse format"
msgstr "Konnte Format nicht parsen."
#: ref-filter.c:870
#, c-format
msgid "expected format: %%(align:<width>,<position>)"
-msgstr ""
+msgstr "Erwartetes Format: %%(align:<Breite>,<Position>)"
#: ref-filter.c:893
#, c-format
msgid "improper format entered align:%s"
-msgstr ""
+msgstr "Sie haben ein ungültiges Format eingegeben align:%s"
#: ref-filter.c:898
#, c-format
msgid "positive width expected with the %%(align) atom"
-msgstr ""
+msgstr "Positive Breitenangabe für %%(align) erwartet"
#: ref-filter.c:1219
#, c-format
msgid "malformed object at '%s'"
msgstr "fehlerhaftes Objekt bei '%s'"
#: ref-filter.c:1561
#, c-format
msgid "format: %%(end) atom missing"
-msgstr ""
+msgstr "Format: %%(end) Atom fehlt"
#: ref-filter.c:1615
#, c-format
msgid "malformed object name %s"
msgstr "Missgebildeter Objektname %s"
#: remote.c:756
@@ -2632,22 +2631,20 @@ msgstr ""
#: builtin/am.c:2220
#, c-format
msgid "Invalid value for --patch-format: %s"
msgstr "Ungültiger Wert für --patch-format: %s"
#: builtin/am.c:2253
-#, fuzzy
msgid "git am [<options>] [(<mbox>|<Maildir>)...]"
-msgstr "git am [Optionen] [(<mbox>|<E-Mail-Verzeichnis>)...]"
+msgstr "git am [<Optionen>] [(<mbox>|<E-Mail-Verzeichnis>)...]"
#: builtin/am.c:2254
-#, fuzzy
msgid "git am [<options>] (--continue | --skip | --abort)"
-msgstr "git am [Optionen] (--continue | --skip | --abort)"
+msgstr "git am [<Optionen>] (--continue | --skip | --abort)"
#: builtin/am.c:2260
msgid "run interactively"
msgstr "interaktiv ausführen"
#: builtin/am.c:2262
msgid "historical option -- no-op"
@@ -3476,17 +3473,16 @@ msgid "git branch [<options>] [-r] (-d | -D) <branch-name>..."
msgstr "git branch [<Optionen>] [-r] (-d | -D) <Branchname>..."
#: builtin/branch.c:28
msgid "git branch [<options>] (-m | -M) [<old-branch>] <new-branch>"
msgstr "git branch [<Optionen>] (-m | -M) [<alter-Branch>] <neuer-Branch>"
#: builtin/branch.c:29
-#, fuzzy
msgid "git branch [<options>] [-r | -a] [--points-at]"
-msgstr "git branch [<Optionen>] [-r | -a] [--merged | --no-merged]"
+msgstr "git branch [<Optionen>] [-r | -a] [--points-at]"
#: builtin/branch.c:142
#, c-format
msgid ""
"deleting branch '%s' that has been merged to\n"
" '%s', but not yet merged to HEAD."
msgstr ""
@@ -3738,22 +3734,20 @@ msgid "edit the description for the branch"
msgstr "die Beschreibung für den Branch bearbeiten"
#: builtin/branch.c:644
msgid "force creation, move/rename, deletion"
msgstr "Erstellung, Verschiebung/Umbenennung oder Löschung erzwingen"
#: builtin/branch.c:645
-#, fuzzy
msgid "print only branches that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Branches ausgeben"
#: builtin/branch.c:646
-#, fuzzy
msgid "print only branches that are not merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur nicht zusammengeführte Branches ausgeben"
#: builtin/branch.c:647
msgid "list branches in columns"
msgstr "Branches in Spalten auflisten"
#: builtin/branch.c:648 builtin/for-each-ref.c:38 builtin/tag.c:366
msgid "key"
@@ -3766,17 +3760,16 @@ msgstr "sortiere nach diesem Feld"
#: builtin/branch.c:651 builtin/for-each-ref.c:41 builtin/notes.c:398
#: builtin/notes.c:401 builtin/notes.c:561 builtin/notes.c:564
#: builtin/tag.c:369
msgid "object"
msgstr "Objekt"
#: builtin/branch.c:652
-#, fuzzy
msgid "print only branches of the object"
-msgstr "nur Tags von dem Objekt ausgeben"
+msgstr "nur Branches von diesem Objekt ausgeben"
#: builtin/branch.c:670
msgid "Failed to resolve HEAD as a valid ref."
msgstr "Konnte HEAD nicht als gültige Referenz auflösen."
#: builtin/branch.c:674 builtin/clone.c:697
msgid "HEAD not found below refs/heads!"
@@ -3908,19 +3901,16 @@ msgid ""
"git cat-file (-t [--allow-unknown-type]|-s [--allow-unknown-type]|-e|-p|"
"<type>|--textconv) <object>"
msgstr ""
"git cat-file (-t [--allow-unknown-type]|-s [--allow-unknown-type]|-e|-p|"
"<Art>|--textconv) <Objekt>"
#: builtin/cat-file.c:429
-#, fuzzy
msgid "git cat-file (--batch | --batch-check) [--follow-symlinks]"
-msgstr ""
-"git cat-file (--batch | --batch-check) [--follow-symlinks] < <Liste-von-"
-"Objekten"
+msgstr "git cat-file (--batch | --batch-check) [--follow-symlinks]"
#: builtin/cat-file.c:466
msgid "<type> can be one of: blob, tree, commit, tag"
msgstr "<Art> kann sein: blob, tree, commit, tag"
#: builtin/cat-file.c:467
msgid "show object type"
@@ -3972,18 +3962,16 @@ msgid "show all objects with --batch or --batch-check"
msgstr "alle Objekte mit --batch oder --batch-check anzeigen"
#: builtin/check-attr.c:11
msgid "git check-attr [-a | --all | <attr>...] [--] <pathname>..."
msgstr "git check-attr [-a | --all | <Attribut>...] [--] <Pfadname>..."
#: builtin/check-attr.c:12
-#, fuzzy
msgid "git check-attr --stdin [-z] [-a | --all | <attr>...]"
-msgstr ""
-"git check-attr --stdin [-z] [-a | --all | <Attribut>...] < <Liste-von-Pfaden>"
+msgstr "git check-attr --stdin [-z] [-a | --all | <Attribut>...]"
#: builtin/check-attr.c:19
msgid "report all attributes set on file"
msgstr "alle Attribute einer Datei ausgeben"
#: builtin/check-attr.c:20
msgid "use .gitattributes only from the index"
@@ -4697,17 +4685,18 @@ msgid "key=value"
msgstr "Schlüssel=Wert"
#: builtin/clone.c:94
msgid "set config inside the new repository"
msgstr "Konfiguration innerhalb des neuen Repositories setzen"
#: builtin/clone.c:300
-#, fuzzy, c-format
+#, c-format
msgid "reference repository '%s' as a linked checkout is not supported yet."
-msgstr "Referenziertes Repository '%s' ist kein lokales Repository."
+msgstr "Referenziertes Repository '%s' wird noch nicht als verknüpftes\n"
+"Arbeitsverzeichnis unterstützt."
#: builtin/clone.c:302
#, c-format
msgid "reference repository '%s' is not a local repository."
msgstr "Referenziertes Repository '%s' ist kein lokales Repository."
#: builtin/clone.c:307
@@ -6228,27 +6217,24 @@ msgid "file to read from"
msgstr "Datei zum Einlesen"
#: builtin/for-each-ref.c:9
msgid "git for-each-ref [<options>] [<pattern>]"
msgstr "git for-each-ref [<Optionen>] [<Muster>]"
#: builtin/for-each-ref.c:10
-#, fuzzy
msgid "git for-each-ref [--points-at <object>]"
-msgstr "git for-each-ref [<Optionen>] [<Muster>]"
+msgstr "git for-each-ref [--points-at <Objekt>]"
#: builtin/for-each-ref.c:11
-#, fuzzy
msgid "git for-each-ref [(--merged | --no-merged) [<object>]]"
-msgstr "git branch [<Optionen>] [-r | -a] [--merged | --no-merged]"
+msgstr "git for-each-ref [(--merged | --no-merged) [<Objekt>]]"
#: builtin/for-each-ref.c:12
-#, fuzzy
msgid "git for-each-ref [--contains [<object>]]"
-msgstr "git for-each-ref [<Optionen>] [<Muster>]"
+msgstr "git for-each-ref [--contains [<Objekt>]]"
#: builtin/for-each-ref.c:27
msgid "quote placeholders suitably for shells"
msgstr "Platzhalter als Shell-String formatieren"
#: builtin/for-each-ref.c:29
msgid "quote placeholders suitably for perl"
@@ -6267,32 +6253,28 @@ msgid "show only <n> matched refs"
msgstr "nur <n> passende Referenzen anzeigen"
#: builtin/for-each-ref.c:37 builtin/tag.c:372
msgid "format to use for the output"
msgstr "für die Ausgabe zu verwendendes Format"
#: builtin/for-each-ref.c:41
-#, fuzzy
msgid "print only refs which points at the given object"
-msgstr "nur Tags von dem Objekt ausgeben"
+msgstr "nur auf dieses Objekt zeigende Referenzen ausgeben"
#: builtin/for-each-ref.c:43
-#, fuzzy
msgid "print only refs that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Referenzen ausgeben"
#: builtin/for-each-ref.c:44
-#, fuzzy
msgid "print only refs that are not merged"
-msgstr "nur Branches ausgeben, die nicht zusammengeführt sind"
+msgstr "nur nicht zusammengeführte Referenzen ausgeben"
#: builtin/for-each-ref.c:45
-#, fuzzy
msgid "print only refs which contain the commit"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur Referenzen ausgeben, die diesen Commit enthalten"
#: builtin/fsck.c:156 builtin/prune.c:140
msgid "Checking connectivity"
msgstr "Prüfe Konnektivität"
#: builtin/fsck.c:486
msgid "Checking object directories"
@@ -6369,14 +6351,20 @@ msgstr "zu langes Objekt-Verzeichnis %.*s"
msgid ""
"The last gc run reported the following. Please correct the root cause\n"
"and remove %s.\n"
"Automatic cleanup will not be performed until the file is removed.\n"
"\n"
"%s"
msgstr ""
+"Die letzte Ausführung von \"gc run\" enthielt die folgenden Meldungen.\n"
+"Bitte beheben Sie das Hauptproblem und löschen Sie %s.\n"
+"Ein automatischer Cleanup wird nicht ausgeführt, bis diese Datei entfernt\n"
+"wurde.\n"
+"\n"
+"%s"
#: builtin/gc.c:327
msgid "prune unreferenced objects"
msgstr "unreferenzierte Objekte entfernen"
#: builtin/gc.c:329
msgid "be more thorough (increased runtime)"
@@ -6664,17 +6652,16 @@ msgid ""
"git hash-object [-t <type>] [-w] [--path=<file> | --no-filters] [--stdin] "
"[--] <file>..."
msgstr ""
"git hash-object [-t <Art>] [-w] [--path=<Datei> | --no-filters] [--stdin] "
"[--] <Datei>..."
#: builtin/hash-object.c:81
-#, fuzzy
msgid "git hash-object --stdin-paths"
-msgstr "git hash-object --stdin-paths < <Liste-von-Pfaden>"
+msgstr "git hash-object --stdin-paths"
#: builtin/hash-object.c:92
msgid "type"
msgstr "Art"
#: builtin/hash-object.c:92
msgid "object type"
@@ -7397,15 +7384,15 @@ msgstr "[PATCH] nicht entfernen/hinzufügen"
#: builtin/log.c:1239
msgid "don't output binary diffs"
msgstr "keine binären Unterschiede ausgeben"
#: builtin/log.c:1241
msgid "output all-zero hash in From header"
-msgstr ""
+msgstr "Hash mit Nullen in \"From\"-Header ausgeben"
#: builtin/log.c:1243
msgid "don't include a patch matching a commit upstream"
msgstr ""
"keine Patches einschließen, die einem Commit im Upstream-Branch entsprechen"
#: builtin/log.c:1245
@@ -8825,20 +8812,18 @@ msgid "report pruned objects"
msgstr "gelöschte Objekte melden"
#: builtin/prune.c:109 builtin/worktree.c:127
msgid "expire objects older than <time>"
msgstr "Objekte älter als <Zeit> verfallen lassen"
#: builtin/prune.c:123
-#, fuzzy
msgid "cannot prune in a precious-objects repo"
-msgstr "Kann existierendes Objekt %s nicht lesen."
+msgstr "kann \"prune\" in precious-objects Repository nicht ausführen"
#: builtin/pull.c:69
-#, fuzzy
msgid "git pull [<options>] [<repository> [<refspec>...]]"
msgstr "git pull [<Optionen>] [<Repository> [<Refspec>...]]"
#: builtin/pull.c:113
msgid "Options related to merging"
msgstr "Optionen bezogen auf Merge"
@@ -9300,17 +9285,16 @@ msgid "refname>:<expect"
msgstr "Referenzname>:<Erwartungswert"
#: builtin/push.c:548 builtin/send-pack.c:176
msgid "require old value of ref to be at this value"
msgstr "Referenz muss sich auf dem angegebenen Wert befinden"
#: builtin/push.c:550
-#, fuzzy
msgid "check|on-demand|no"
-msgstr "bei-Bedarf"
+msgstr "check|on-demand|no"
#: builtin/push.c:551
msgid "control recursive pushing of submodules"
msgstr "rekursiven \"push\" von Submodulen steuern"
#: builtin/push.c:553 builtin/send-pack.c:169
msgid "use thin pack"
@@ -9477,17 +9461,16 @@ msgstr ""
"git remote [-v | --verbose] update [-p | --prune] [(<Gruppe> | <Remote>)...]"
#: builtin/remote.c:20
msgid "git remote set-branches [--add] <name> <branch>..."
msgstr "git remote set-branches [--add] <Name> <Branch>..."
#: builtin/remote.c:21 builtin/remote.c:70
-#, fuzzy
msgid "git remote get-url [--push] [--all] <name>"
-msgstr "git remote set-url [--push] <Name> <neueURL> [<alteURL>]"
+msgstr "git remote get-url [--push] [--all] <Name>"
#: builtin/remote.c:22 builtin/remote.c:75
msgid "git remote set-url [--push] <name> <newurl> [<oldurl>]"
msgstr "git remote set-url [--push] <Name> <neueURL> [<alteURL>]"
#: builtin/remote.c:23 builtin/remote.c:76
msgid "git remote set-url --add <name> <newurl>"
@@ -9903,24 +9886,24 @@ msgstr "Branch hinzufügen"
#: builtin/remote.c:1468
msgid "no remote specified"
msgstr "kein Remote-Repository angegeben"
#: builtin/remote.c:1485
msgid "query push URLs rather than fetch URLs"
-msgstr ""
+msgstr "nur URLs für Push ausgeben"
#: builtin/remote.c:1487
msgid "return all URLs"
-msgstr ""
+msgstr "alle URLs ausgeben"
#: builtin/remote.c:1515
-#, fuzzy, c-format
+#, c-format
msgid "no URLs configured for remote '%s'"
-msgstr "Kein Upstream-Branch für Branch '%s' konfiguriert."
+msgstr "Keine URLs für Remote-Repository '%s' konfiguriert."
#: builtin/remote.c:1541
msgid "manipulate push URLs"
msgstr "URLs für \"push\" manipulieren"
#: builtin/remote.c:1543
msgid "add URL"
@@ -10022,15 +10005,15 @@ msgstr "maximale Größe für jede Paketdatei"
#: builtin/repack.c:187
msgid "repack objects in packs marked with .keep"
msgstr ""
"Objekte umpacken, die sich in mit .keep markierten Pack-Dateien befinden"
#: builtin/repack.c:197
msgid "cannot delete packs in a precious-objects repo"
-msgstr ""
+msgstr "kann Pack-Dateien in precious-objects Repository nicht löschen"
#: builtin/repack.c:381
#, c-format
msgid "removing '%s' failed"
msgstr "Löschen von '%s' fehlgeschlagen"
#: builtin/replace.c:19
@@ -10628,17 +10611,16 @@ msgid ""
"git show-ref [-q | --quiet] [--verify] [--head] [-d | --dereference] [-s | --"
"hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<pattern>...]"
msgstr ""
"git show-ref [-q | --quiet] [--verify] [--head] [-d | --dereference] [-s | --"
"hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<Muster>...] "
#: builtin/show-ref.c:11
-#, fuzzy
msgid "git show-ref --exclude-existing[=<pattern>]"
-msgstr "git show-ref --exclude-existing[=<Muster>] < <Referenzliste>"
+msgstr "git show-ref --exclude-existing[=<Muster>]"
#: builtin/show-ref.c:165
msgid "only show tags (can be combined with heads)"
msgstr "nur Tags anzeigen (kann mit \"heads\" kombiniert werden)"
#: builtin/show-ref.c:166
msgid "only show heads (can be combined with tags)"
@@ -10670,104 +10652,104 @@ msgstr ""
msgid "show refs from stdin that aren't in local repository"
msgstr ""
"Referenzen von der Standard-Eingabe anzeigen, die sich nicht im lokalen "
"Repository befinden"
#: builtin/stripspace.c:17
msgid "git stripspace [-s | --strip-comments]"
-msgstr ""
+msgstr "git stripspace [-s | --strip-comments]"
#: builtin/stripspace.c:18
msgid "git stripspace [-c | --comment-lines]"
-msgstr ""
+msgstr "git stripspace [-c | --comment-lines]"
#: builtin/stripspace.c:35
msgid "skip and remove all lines starting with comment character"
-msgstr ""
+msgstr "alle Zeilen, die mit dem Kommentarzeichen beginnen, überspringen und "
+"entfernen"
#: builtin/stripspace.c:38
msgid "prepend comment character and blank to each line"
-msgstr ""
+msgstr "Kommentarzeichen mit Leerzeichen an jeder Zeile voranstellen"
#: builtin/submodule--helper.c:79 builtin/submodule--helper.c:167
msgid "alternative anchor for relative paths"
-msgstr ""
+msgstr "Alternativer Anker für relative Pfade"
#: builtin/submodule--helper.c:84
msgid "git submodule--helper list [--prefix=<path>] [<path>...]"
-msgstr ""
+msgstr "git submodule--helper list [--prefix=<Pfad>] [<Pfad>...]"
#: builtin/submodule--helper.c:114
msgid "git submodule--helper name <path>"
-msgstr ""
+msgstr "git submodule--helper name <Pfad>"
#: builtin/submodule--helper.c:120
-#, fuzzy, c-format
+#, c-format
msgid "no submodule mapping found in .gitmodules for path '%s'"
-msgstr "Keine Submodul-Zuordnung in .gitmodules für Pfad '$sm_path' gefunden"
+msgstr "Keine Submodul-Zuordnung in .gitmodules für Pfad '%s' gefunden"
#: builtin/submodule--helper.c:170
msgid "where the new submodule will be cloned to"
-msgstr ""
+msgstr "Pfad für neues Submodul"
#: builtin/submodule--helper.c:173
-#, fuzzy
msgid "name of the new submodule"
-msgstr "Aktualisierung: ignoriert Submodule"
+msgstr "Name des neuen Submoduls"
#: builtin/submodule--helper.c:176
msgid "url where to clone the submodule from"
-msgstr ""
+msgstr "URL von der das Submodul geklont wird"
#: builtin/submodule--helper.c:182
-#, fuzzy
msgid "depth for shallow clones"
-msgstr ""
-"die Historie eines Klons mit unvollständiger Historie (shallow) vertiefen"
+msgstr "Tiefe des Klons mit unvollständiger Historie (shallow)"
#: builtin/submodule--helper.c:188
msgid ""
"git submodule--helper clone [--prefix=<path>] [--quiet] [--reference "
"<repository>] [--name <name>] [--url <url>][--depth <depth>] [--] [<path>...]"
msgstr ""
+"git submodule--helper clone [--prefix=<Pfad>] [--quiet] [--reference "
+"<Repository>] [--name <Name>] [--url <URL>][--depth <Tiefe>] [--] [<Pfad>...]"
#: builtin/submodule--helper.c:202 builtin/submodule--helper.c:208
#: builtin/submodule--helper.c:216
-#, fuzzy, c-format
+#, c-format
msgid "could not create directory '%s'"
msgstr "Konnte Verzeichnis '%s' nicht erstellen."
#: builtin/submodule--helper.c:204
-#, fuzzy, c-format
+#, c-format
msgid "clone of '%s' into submodule path '%s' failed"
-msgstr "Klonen von '$url' in Submodul-Pfad '$sm_path' fehlgeschlagen"
+msgstr "Klonen von '%s' in Submodul-Pfad '%s' fehlgeschlagen"
#: builtin/submodule--helper.c:227
-#, fuzzy, c-format
+#, c-format
msgid "cannot open file '%s'"
-msgstr "Kann Paketdatei '%s' nicht öffnen"
+msgstr "Kann Datei '%s' nicht öffnen"
#: builtin/submodule--helper.c:232
-#, fuzzy, c-format
+#, c-format
msgid "could not close file %s"
-msgstr "Konnte '%s' nicht schließen."
+msgstr "Konnte Datei '%s' nicht schließen."
#: builtin/submodule--helper.c:247
-#, fuzzy, c-format
+#, c-format
msgid "could not get submodule directory for '%s'"
-msgstr "Konnte Verzeichnis '%s' nicht erstellen."
+msgstr "Konnte Submodul-Verzeichnis '%s' nicht finden."
#: builtin/submodule--helper.c:273
msgid "fatal: submodule--helper subcommand must be called with a subcommand"
-msgstr ""
+msgstr "fatal: submodule--helper muss mit einem Unterkommando aufgerufen werden"
#: builtin/submodule--helper.c:280
#, c-format
msgid "fatal: '%s' is not a valid submodule--helper subcommand"
-msgstr ""
+msgstr "fatal: '%s' ist kein gültiges Unterkommando von submodule--helper"
#: builtin/symbolic-ref.c:7
msgid "git symbolic-ref [<options>] <name> [<ref>]"
msgstr "git symbolic-ref [<Optionen>] <Name> [<Referenz>]"
#: builtin/symbolic-ref.c:8
msgid "git symbolic-ref -d [-q] <name>"
@@ -10803,21 +10785,20 @@ msgstr ""
"<Tagname> [<Commit>]"
#: builtin/tag.c:24
msgid "git tag -d <tagname>..."
msgstr "git tag -d <Tagname>..."
#: builtin/tag.c:25
-#, fuzzy
msgid ""
"git tag -l [-n[<num>]] [--contains <commit>] [--points-at <object>]\n"
"\t\t[--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]"
msgstr ""
"git tag -l [-n[<Nummer>]] [--contains <Commit>] [--points-at <Objekt>]\n"
-"\t\t[<Muster>...]"
+"\t\t[--format=<Muster>] [--[no-]merged [<Commit>]] [<Muster>...]"
#: builtin/tag.c:27
msgid "git tag -v <tagname>..."
msgstr "git tag -v <Tagname>..."
#: builtin/tag.c:80
#, c-format
@@ -10945,22 +10926,20 @@ msgid "show tag list in columns"
msgstr "Liste der Tags in Spalten anzeigen"
#: builtin/tag.c:362 builtin/tag.c:363
msgid "print only tags that contain the commit"
msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
#: builtin/tag.c:364
-#, fuzzy
msgid "print only tags that are merged"
-msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
+msgstr "nur Tags ausgeben, die gemerged wurden"
#: builtin/tag.c:365
-#, fuzzy
msgid "print only tags that are not merged"
-msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
+msgstr "nur Tags ausgeben, die nicht gemerged wurden"
#: builtin/tag.c:370
msgid "print only tags of the object"
msgstr "nur Tags von dem Objekt ausgeben"
#: builtin/tag.c:399
msgid "--column and -n are incompatible"
@@ -10975,17 +10954,16 @@ msgid "--contains option is only allowed with -l."
msgstr "--contains Option ist nur erlaubt mit -l."
#: builtin/tag.c:423
msgid "--points-at option is only allowed with -l."
msgstr "--points-at Option ist nur erlaubt mit -l."
#: builtin/tag.c:425
-#, fuzzy
msgid "--merged and --no-merged option are only allowed with -l"
-msgstr "-n Option ist nur erlaubt mit -l."
+msgstr "Die Optionen --merged und --no-merged sind nur mit -l erlaubt."
#: builtin/tag.c:433
msgid "only one -F or -m option is allowed."
msgstr "nur eine -F oder -m Option ist erlaubt."
#: builtin/tag.c:453
msgid "too many params"
@@ -11276,26 +11254,24 @@ msgid "git verify-tag [-v | --verbose] <tag>..."
msgstr "git verify-tag [-v | --verbose] <Tag>..."
#: builtin/verify-tag.c:83
msgid "print tag contents"
msgstr "Tag-Inhalte ausgeben"
#: builtin/worktree.c:15
-#, fuzzy
msgid "git worktree add [<options>] <path> [<branch>]"
-msgstr "git worktree add [<Optionen>] <Pfad> <Branch>"
+msgstr "git worktree add [<Optionen>] <Pfad> [<Branch>]"
#: builtin/worktree.c:16
msgid "git worktree prune [<options>]"
msgstr "git worktree prune [<Optionen>]"
#: builtin/worktree.c:17
-#, fuzzy
msgid "git worktree list [<options>]"
-msgstr "git worktree prune [<Optionen>]"
+msgstr "git worktree list [<Optionen>]"
#: builtin/worktree.c:39
#, c-format
msgid "Removing worktrees/%s: not a valid directory"
msgstr "Lösche worktrees/%s: kein gültiges Verzeichnis"
#: builtin/worktree.c:45
@@ -11692,48 +11668,50 @@ msgstr ""
#: git-bisect.sh:538
msgid "bisect run success"
msgstr "'bisect run' erfolgreich ausgeführt"
#: git-bisect.sh:565
msgid "please use two different terms"
-msgstr ""
+msgstr "Bitte verwenden Sie zwei verschiedene Begriffe."
#: git-bisect.sh:575
-#, fuzzy, sh-format
+#, sh-format
msgid "'$term' is not a valid term"
-msgstr "'%s' ist kein gültiger Zeitstempel"
+msgstr "'$term' ist kein gültiger Begriff"
#: git-bisect.sh:578
#, sh-format
msgid "can't use the builtin command '$term' as a term"
-msgstr ""
+msgstr "Kann eingebautes Kommando '$term' nicht als Begriff verwenden"
#: git-bisect.sh:587 git-bisect.sh:593
#, sh-format
msgid "can't change the meaning of term '$term'"
-msgstr ""
+msgstr "Kann Bedeutung von '$term' nicht ändern."
#: git-bisect.sh:606
#, sh-format
msgid "Invalid command: you're currently in a $TERM_BAD/$TERM_GOOD bisect."
msgstr ""
"Ungültiges Kommando: Sie sind gerade bei einer binären $TERM_BAD/$TERM_GOOD "
"Suche."
#: git-bisect.sh:636
msgid "no terms defined"
-msgstr ""
+msgstr "Keine Begriffe definiert."
#: git-bisect.sh:653
#, sh-format
msgid ""
"invalid argument $arg for 'git bisect terms'.\n"
"Supported options are: --term-good|--term-old and --term-bad|--term-new."
msgstr ""
+"Ungültiges Argument $arg für 'git bisect terms'.\n"
+"Unterstützte Optionen sind: --term-good|--term-old und --term-bad|--term-new."
#: git-rebase.sh:57
msgid ""
"When you have resolved this problem, run \"git rebase --continue\".\n"
"If you prefer to skip this patch, run \"git rebase --skip\" instead.\n"
"To check out the original branch and stop rebasing, run \"git rebase --abort"
"\"."
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related [relevance 5%]
* [RFC PATCH] Teach checkout the -n|--dry-run option
@ 2010-09-04 20:19 5% Jens Lehmann
0 siblings, 0 replies; 200+ results
From: Jens Lehmann @ 2010-09-04 20:19 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
This option can be used to determine if checking out a branch or commit
would touch files which are modified in the work tree. It doesn't change
the work tree contents or the index, so it can only tell if the checkout
would succeed using trivial merges.
It can neither be used when checking out only certain paths nor together
with the '-m' option.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I need this new option for the recursive submodule checkout. Denying a
checkout inside a submodule just because it has modifications is a too
limiting condition (and it is way too expensive to check the whole tree,
just looking at those paths going to be changed by the checkout should
be much faster, especially for large submodules).
IMO the same behavior that applies for a checkout in the superproject
should apply for the checkout inside the submodule: no local changes
may be overwritten by the checkout (and the HEAD must match the commit
recorded in the superproject, but that is handled elsewhere).
To be able to test that, I added the -n|--dry-run option to checkout.
I think I found all relevant places, but a few more eyeballs are highly
appreciated as I am not very familiar with this part of the code.
A thing I'm not so sure about is the output of show_local_changes(),
with -n it doesn't show the changes as they would have been *after* the
- not executed - checkout but *without* having done it.
Is that a problem here?
Documentation/git-checkout.txt | 13 +++++++++++--
builtin/checkout.c | 20 +++++++++++++++-----
t/t2018-checkout-branch.sh | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index f88e997..32c5c77 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree
SYNOPSIS
--------
[verse]
-'git checkout' [-q] [-f] [-m] [<branch>]
-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
+'git checkout' [-q] [-f] [-m|-n] [<branch>]
+'git checkout' [-q] [-f] [-m|-n] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' --patch [<tree-ish>] [--] [<paths>...]
@@ -77,6 +77,13 @@ OPTIONS
When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.
+-n::
+--dry-run::
+ Don't really checkout the file(s), just check if it would succeed
+ using only trivial merges. Using this option will not touch the work
+ tree or the index. The command will fail when the checkout would change
+ locally modified files. This option can not be used together with `-m`.
+
--ours::
--theirs::
When checking out paths from the index, check out stage #2
@@ -158,6 +165,8 @@ should result in deletion of the path).
+
When checking out paths from the index, this option lets you recreate
the conflicted merge in the specified paths.
++
+This option does not work together with '-n'.
--conflict=<style>::
The same as --merge option above, but changes the way the
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f365169..ba6ca24 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -32,6 +32,7 @@ struct checkout_opts {
int force;
int writeout_stage;
int writeout_error;
+ int dry_run;
/* not set by parse_options */
int branch_exists;
@@ -370,6 +371,8 @@ static int merge_working_tree(struct checkout_opts *opts,
resolve_undo_clear();
if (opts->force) {
+ if (opts->dry_run)
+ return 0;
ret = reset_tree(new->commit->tree, opts, 1);
if (ret)
return ret;
@@ -394,7 +397,7 @@ static int merge_working_tree(struct checkout_opts *opts,
/* 2-way merge to the new branch */
topts.initial_checkout = is_cache_unborn();
- topts.update = 1;
+ topts.update = !opts->dry_run;
topts.merge = 1;
topts.gently = opts->merge && old->commit;
topts.verbose_update = !opts->quiet;
@@ -469,8 +472,8 @@ static int merge_working_tree(struct checkout_opts *opts,
}
}
- if (write_cache(newfd, active_cache, active_nr) ||
- commit_locked_index(lock_file))
+ if (!opts->dry_run && (write_cache(newfd, active_cache, active_nr) ||
+ commit_locked_index(lock_file)))
die("unable to write new index file");
if (!opts->force && !opts->quiet)
@@ -603,7 +606,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
}
ret = merge_working_tree(opts, &old, new);
- if (ret)
+ if (ret || opts->dry_run)
return ret;
/*
@@ -704,6 +707,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('m', "merge", &opts.merge, "merge"),
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
+ OPT_BOOLEAN('n', "dry-run", &opts.dry_run, "show if the checkout would fail because it touches locally modified files"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
{ OPTION_BOOLEAN, 0, "guess", &dwim_new_local_branch, NULL,
"second guess 'git checkout no-such-branch'",
@@ -731,7 +735,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.new_branch_force)
opts.new_branch = opts.new_branch_force;
- if (patch_mode && (opts.track > 0 || opts.new_branch
+ if (patch_mode && (opts.track > 0 || opts.new_branch || opts.dry_run
|| opts.new_branch_log || opts.merge || opts.force))
die ("--patch is incompatible with all other options");
@@ -766,6 +770,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.force && opts.merge)
die("git checkout: -f and -m are incompatible");
+ if (opts.merge && opts.dry_run)
+ die("git checkout: -m and -n are incompatible");
+
/*
* case 1: git checkout <ref> -- [<paths>]
*
@@ -890,6 +897,9 @@ no_reference:
if (1 < !!opts.writeout_stage + !!opts.force + !!opts.merge)
die("git checkout: --ours/--theirs, --force and --merge are incompatible when\nchecking out of the index.");
+ if (opts.dry_run)
+ die("git checkout: updating paths is incompatible with -n.");
+
return checkout_paths(source_tree, pathspec, &opts);
}
diff --git a/t/t2018-checkout-branch.sh b/t/t2018-checkout-branch.sh
index fa69016..61c82ef 100755
--- a/t/t2018-checkout-branch.sh
+++ b/t/t2018-checkout-branch.sh
@@ -169,4 +169,27 @@ test_expect_success 'checkout -f -B to an existing branch with mergeable changes
test_must_fail test_dirty_mergeable
'
+test_expect_success 'checkout -n/--dry-run does not change work tree or index' '
+ echo precious >expect &&
+ echo precious >file1 &&
+ test_must_fail git checkout -n branch1 &&
+ test_cmp expect file1 &&
+ git checkout --dry-run -f branch1 &&
+ test_cmp expect file1 &&
+ test_must_fail git checkout -b new_branch --dry-run branch1 &&
+ test_cmp expect file1 &&
+ git checkout -b new_branch -n -f branch1 &&
+ test_cmp expect file1 &&
+ git checkout -f branch1 &&
+ git status -s -uno > actual &&
+ ! test -s actual &&
+ git checkout -n HEAD^ &&
+ git status -s -uno > actual &&
+ ! test -s actual
+'
+
+test_expect_success 'checkout -n/--dry-run is not allowed when checking out only certain paths' '
+ test_must_fail git checkout -n branch1 file1 &&
+ test_must_fail git checkout -n HEAD file1
+'
test_done
--
1.7.2.2.570.ga3f70
^ permalink raw reply related [relevance 5%]
* Re: [PATCH 6/9] repack: add `--filter=<filter-spec>` option
@ 2023-06-16 0:43 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2023-06-16 0:43 UTC (permalink / raw)
To: Christian Couder
Cc: git, John Cai, Jonathan Tan, Jonathan Nieder, Taylor Blau,
Derrick Stolee, Patrick Steinhardt, Christian Couder
Christian Couder <christian.couder@gmail.com> writes:
> After cloning with --filter=<filter-spec>, for example to avoid
> getting unneeded large files on a user machine, it's possible
> that some of these large files still get fetched for some reasons
> (like checking out old branches) over time.
>
> In this case the repo size could grow too much for no good reason and a
> way to filter out some objects would be useful to remove the unneeded
> large files.
Makes sense.
If we repack without these objects, when the repository has a
promisor remote, we should be able to rely on that remote to supply
them on demand, once we need them again, no?
> Deleting objects right away could corrupt a repo though,...
Hmph, could you elaborate why it is the case? Isn't it the whole
point to have promisor remote and use a lazy clone with the --filter
option, so that objects that _ought_ to exist from connectivity's
point of view _are_ allowed to be missing because the promisor
promises to make them available on-demand?
Side note: I think I know the answer. While trying to remove
UNNEEDED large files, doing so may discard NEEDED large
files when done carelessly (e.g. the file may have been
created locally and haven't been pushed back). But (1) if
that is the problem, perhaps we should be more careful in
the first place? (2) if it inherently is impossible to tell
which ones are unneeded reliably, the reason why it is
impossible, and the reason why "try sifting into two bins,
one that we _think_ are unneeded and another for the rest,
and verify what we _thought_ are unneeded are all available
from the promisor remote" is the best we can do, must be
described, I think.
> ... so it might be
> better to put those objects into a separate packfile instead of
> deleting them. The separate pack could then be removed after checking
> that all the objects in it are still available on a promisor remote it
> can access.
Surely, sifting the objects into two bins (i.e. those that we
wouldn't have received if we cloned from the promisor remote just
now, which are prunable, and those that we cannot lose because the
promisor remote would not have them, e.g. we created them and have
not pushed them to the remote yet) without removing anything would
be safe, but if the result of such sifting must be verified, doesn't
it indicate that the sifting step was buggy or misdesigned? It does
not sound like a very good justification to save them in a separate
packfile. It does smell somewhat similar to the cruft packs but not
really (the choice over there is between exploding to loose and
keeping in a pack, and never involves loss of objects).
> Also splitting a packfile into 2 packs depending on a filter could be
> useful in other usecases. For example some large blobs might take a lot
> of precious space on fast storage while they are rarely accessed, and
> it could make sense to move them in a separate cheaper, though slower,
> storage.
This one, outside the context of partial clone client, does make
tons of sense.
I guess what I suspect is that this option, while it would be very
useful for the "in other usecases" scenario above, may not become
all that useful in the "our lazy clone got bloated and we want to
trim objects we know we can retrieve from the promisor remote again
if necessary" scenario, until the repack machinery learns to use an
extra piece of information (namely "these are objects that we can
fetch from the promisor remote") at the same time.
> This commit implements a new `--filter=<filter-spec>` option in
> `git repack` that moves filtered out objects into a separate pack.
>
> This is done by reading filtered out objects from `git pack-objects`'s
> output and piping them into a separate `git pack-objects` process that
> will put them into a separate packfile.
So, for example, you may say "no blobs" in the filter, and while
packing the local repository with the filter, resulting in a pack
that exclude all blobs, we will learn what blob objects we did not
pack into that packfile. We can pack them into a separate one, and
most of the blobs are what we could retrieve again from the promisor
remote, but some of the blobs are what we locally created ourselves
and haven't pushed back to the promisor remote yet. Now what? My
earlier suspicion that this mechanism may not be all that useful for
the "slim bloated lazy clone" comes from that I cannot think of a
good answer to this "Now what?" question---my naive solution would
involve enumerating the objects in that "separate packfile" that is
a mixture of precious ones and expendable ones, and then learning
which ones are precious, and creating a new pack that is a subset of
that "separate packfile" with only the precious ones. But if I do
so, I do not think we need this new mechanism that seems to go only
the half-way.
^ permalink raw reply [relevance 5%]
* [PATCH] l10n: de.po: translate 68 new messages
@ 2015-12-22 17:39 5% Ralf Thielow
2015-12-29 18:18 5% ` [PATCH v3] " Ralf Thielow
0 siblings, 1 reply; 200+ results
From: Ralf Thielow @ 2015-12-22 17:39 UTC (permalink / raw)
To: git
Cc: tr, jk, stimming, phillip.szelat, matthias.ruester,
magnus.goerlitz, Ralf Thielow
Translate 68 new messages came from git.pot update in
f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and
2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 190 ++++++++++++++++++++++++++++-----------------------------------
1 file changed, 84 insertions(+), 106 deletions(-)
diff --git a/po/de.po b/po/de.po
index 1ce4193..4a1fecf 100644
--- a/po/de.po
+++ b/po/de.po
@@ -32,17 +32,16 @@ msgstr ""
"und zu committen."
#: advice.c:101 builtin/merge.c:1225
msgid "You have not concluded your merge (MERGE_HEAD exists)."
msgstr "Sie haben Ihren Merge nicht abgeschlossen (MERGE_HEAD existiert)."
#: advice.c:103
-#, fuzzy
msgid "Please, commit your changes before merging."
-msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie den Merge ausführen."
+msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie mergen."
#: advice.c:104
msgid "Exiting because of unfinished merge."
msgstr "Beende wegen nicht abgeschlossenem Merge."
#: archive.c:12
msgid "git archive [<options>] <tree-ish> [<path>...]"
@@ -1110,54 +1109,54 @@ msgstr "Konnte Referenzen nicht entfernen: %s"
#, c-format
msgid "could not remove reference %s"
msgstr "Konnte Referenz %s nicht löschen"
#: ref-filter.c:245
#, c-format
msgid "format: %%(end) atom used without corresponding atom"
-msgstr ""
+msgstr "format: %%(end) Atom ohne zugehöriges Atom verwendet"
#: ref-filter.c:704
#, c-format
msgid "positive value expected contents:lines=%s"
-msgstr ""
+msgstr "Positiver Wert erwartet contents:lines=%s"
#: ref-filter.c:833
#, c-format
msgid "expected format: %%(color:<color>)"
-msgstr ""
+msgstr "Erwartetes Format: %%(color:<Farbe>)"
#: ref-filter.c:835
msgid "unable to parse format"
msgstr "Konnte Format nicht parsen."
#: ref-filter.c:870
#, c-format
msgid "expected format: %%(align:<width>,<position>)"
-msgstr ""
+msgstr "Erwartetes Format: %%(align:<Breite>,<Position>)"
#: ref-filter.c:893
#, c-format
msgid "improper format entered align:%s"
-msgstr ""
+msgstr "Ungültiges Format eingegeben align:%s"
#: ref-filter.c:898
#, c-format
msgid "positive width expected with the %%(align) atom"
-msgstr ""
+msgstr "Positive Breitenangabe für %%(align) erwartet"
#: ref-filter.c:1219
#, c-format
msgid "malformed object at '%s'"
msgstr "fehlerhaftes Objekt bei '%s'"
#: ref-filter.c:1561
#, c-format
msgid "format: %%(end) atom missing"
-msgstr ""
+msgstr "format: %%(end) Atom fehlt"
#: ref-filter.c:1615
#, c-format
msgid "malformed object name %s"
msgstr "Missgebildeter Objektname %s"
#: remote.c:756
@@ -2632,22 +2631,20 @@ msgstr ""
#: builtin/am.c:2220
#, c-format
msgid "Invalid value for --patch-format: %s"
msgstr "Ungültiger Wert für --patch-format: %s"
#: builtin/am.c:2253
-#, fuzzy
msgid "git am [<options>] [(<mbox>|<Maildir>)...]"
-msgstr "git am [Optionen] [(<mbox>|<E-Mail-Verzeichnis>)...]"
+msgstr "git am [<Optionen>] [(<mbox>|<E-Mail-Verzeichnis>)...]"
#: builtin/am.c:2254
-#, fuzzy
msgid "git am [<options>] (--continue | --skip | --abort)"
-msgstr "git am [Optionen] (--continue | --skip | --abort)"
+msgstr "git am [<Optionen>] (--continue | --skip | --abort)"
#: builtin/am.c:2260
msgid "run interactively"
msgstr "interaktiv ausführen"
#: builtin/am.c:2262
msgid "historical option -- no-op"
@@ -3476,17 +3473,16 @@ msgid "git branch [<options>] [-r] (-d | -D) <branch-name>..."
msgstr "git branch [<Optionen>] [-r] (-d | -D) <Branchname>..."
#: builtin/branch.c:28
msgid "git branch [<options>] (-m | -M) [<old-branch>] <new-branch>"
msgstr "git branch [<Optionen>] (-m | -M) [<alter-Branch>] <neuer-Branch>"
#: builtin/branch.c:29
-#, fuzzy
msgid "git branch [<options>] [-r | -a] [--points-at]"
-msgstr "git branch [<Optionen>] [-r | -a] [--merged | --no-merged]"
+msgstr "git branch [<Optionen>] [-r | -a] [--points-at]"
#: builtin/branch.c:142
#, c-format
msgid ""
"deleting branch '%s' that has been merged to\n"
" '%s', but not yet merged to HEAD."
msgstr ""
@@ -3738,22 +3734,20 @@ msgid "edit the description for the branch"
msgstr "die Beschreibung für den Branch bearbeiten"
#: builtin/branch.c:644
msgid "force creation, move/rename, deletion"
msgstr "Erstellung, Verschiebung/Umbenennung oder Löschung erzwingen"
#: builtin/branch.c:645
-#, fuzzy
msgid "print only branches that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Branches ausgeben"
#: builtin/branch.c:646
-#, fuzzy
msgid "print only branches that are not merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur nicht zusammengeführte Branches ausgeben"
#: builtin/branch.c:647
msgid "list branches in columns"
msgstr "Branches in Spalten auflisten"
#: builtin/branch.c:648 builtin/for-each-ref.c:38 builtin/tag.c:366
msgid "key"
@@ -3766,17 +3760,16 @@ msgstr "sortiere nach diesem Feld"
#: builtin/branch.c:651 builtin/for-each-ref.c:41 builtin/notes.c:398
#: builtin/notes.c:401 builtin/notes.c:561 builtin/notes.c:564
#: builtin/tag.c:369
msgid "object"
msgstr "Objekt"
#: builtin/branch.c:652
-#, fuzzy
msgid "print only branches of the object"
-msgstr "nur Tags von dem Objekt ausgeben"
+msgstr "nur Branches von diesem Objekt ausgeben"
#: builtin/branch.c:670
msgid "Failed to resolve HEAD as a valid ref."
msgstr "Konnte HEAD nicht als gültige Referenz auflösen."
#: builtin/branch.c:674 builtin/clone.c:697
msgid "HEAD not found below refs/heads!"
@@ -3908,19 +3901,16 @@ msgid ""
"git cat-file (-t [--allow-unknown-type]|-s [--allow-unknown-type]|-e|-p|"
"<type>|--textconv) <object>"
msgstr ""
"git cat-file (-t [--allow-unknown-type]|-s [--allow-unknown-type]|-e|-p|"
"<Art>|--textconv) <Objekt>"
#: builtin/cat-file.c:429
-#, fuzzy
msgid "git cat-file (--batch | --batch-check) [--follow-symlinks]"
-msgstr ""
-"git cat-file (--batch | --batch-check) [--follow-symlinks] < <Liste-von-"
-"Objekten"
+msgstr "git cat-file (--batch | --batch-check) [--follow-symlinks]"
#: builtin/cat-file.c:466
msgid "<type> can be one of: blob, tree, commit, tag"
msgstr "<Art> kann sein: blob, tree, commit, tag"
#: builtin/cat-file.c:467
msgid "show object type"
@@ -3972,18 +3962,16 @@ msgid "show all objects with --batch or --batch-check"
msgstr "alle Objekte mit --batch oder --batch-check anzeigen"
#: builtin/check-attr.c:11
msgid "git check-attr [-a | --all | <attr>...] [--] <pathname>..."
msgstr "git check-attr [-a | --all | <Attribut>...] [--] <Pfadname>..."
#: builtin/check-attr.c:12
-#, fuzzy
msgid "git check-attr --stdin [-z] [-a | --all | <attr>...]"
-msgstr ""
-"git check-attr --stdin [-z] [-a | --all | <Attribut>...] < <Liste-von-Pfaden>"
+msgstr "git check-attr --stdin [-z] [-a | --all | <Attribut>...]"
#: builtin/check-attr.c:19
msgid "report all attributes set on file"
msgstr "alle Attribute einer Datei ausgeben"
#: builtin/check-attr.c:20
msgid "use .gitattributes only from the index"
@@ -4697,17 +4685,18 @@ msgid "key=value"
msgstr "Schlüssel=Wert"
#: builtin/clone.c:94
msgid "set config inside the new repository"
msgstr "Konfiguration innerhalb des neuen Repositories setzen"
#: builtin/clone.c:300
-#, fuzzy, c-format
+#, c-format
msgid "reference repository '%s' as a linked checkout is not supported yet."
-msgstr "Referenziertes Repository '%s' ist kein lokales Repository."
+msgstr "Referenziertes Repository '%s' wird noch nicht als verknüpftes\n"
+"Arbeitsverzeichnis unterstützt."
#: builtin/clone.c:302
#, c-format
msgid "reference repository '%s' is not a local repository."
msgstr "Referenziertes Repository '%s' ist kein lokales Repository."
#: builtin/clone.c:307
@@ -6228,27 +6217,24 @@ msgid "file to read from"
msgstr "Datei zum Einlesen"
#: builtin/for-each-ref.c:9
msgid "git for-each-ref [<options>] [<pattern>]"
msgstr "git for-each-ref [<Optionen>] [<Muster>]"
#: builtin/for-each-ref.c:10
-#, fuzzy
msgid "git for-each-ref [--points-at <object>]"
-msgstr "git for-each-ref [<Optionen>] [<Muster>]"
+msgstr "git for-each-ref [--points-at <Objekt>]"
#: builtin/for-each-ref.c:11
-#, fuzzy
msgid "git for-each-ref [(--merged | --no-merged) [<object>]]"
-msgstr "git branch [<Optionen>] [-r | -a] [--merged | --no-merged]"
+msgstr "git for-each-ref [(--merged | --no-merged) [<Objekt>]]"
#: builtin/for-each-ref.c:12
-#, fuzzy
msgid "git for-each-ref [--contains [<object>]]"
-msgstr "git for-each-ref [<Optionen>] [<Muster>]"
+msgstr "git for-each-ref [--contains [<Objekt>]]"
#: builtin/for-each-ref.c:27
msgid "quote placeholders suitably for shells"
msgstr "Platzhalter als Shell-String formatieren"
#: builtin/for-each-ref.c:29
msgid "quote placeholders suitably for perl"
@@ -6267,32 +6253,28 @@ msgid "show only <n> matched refs"
msgstr "nur <n> passende Referenzen anzeigen"
#: builtin/for-each-ref.c:37 builtin/tag.c:372
msgid "format to use for the output"
msgstr "für die Ausgabe zu verwendendes Format"
#: builtin/for-each-ref.c:41
-#, fuzzy
msgid "print only refs which points at the given object"
-msgstr "nur Tags von dem Objekt ausgeben"
+msgstr "nur auf dieses Objekt zeigende Referenzen ausgeben"
#: builtin/for-each-ref.c:43
-#, fuzzy
msgid "print only refs that are merged"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur zusammengeführte Referenzen ausgeben"
#: builtin/for-each-ref.c:44
-#, fuzzy
msgid "print only refs that are not merged"
-msgstr "nur Branches ausgeben, die nicht zusammengeführt sind"
+msgstr "nur nicht zusammengeführte Referenzen ausgeben"
#: builtin/for-each-ref.c:45
-#, fuzzy
msgid "print only refs which contain the commit"
-msgstr "nur Branches ausgeben, welche diesen Commit beinhalten"
+msgstr "nur Referenzen ausgeben, die diesen Commit enthalten"
#: builtin/fsck.c:156 builtin/prune.c:140
msgid "Checking connectivity"
msgstr "Prüfe Konnektivität"
#: builtin/fsck.c:486
msgid "Checking object directories"
@@ -6369,14 +6351,20 @@ msgstr "zu langes Objekt-Verzeichnis %.*s"
msgid ""
"The last gc run reported the following. Please correct the root cause\n"
"and remove %s.\n"
"Automatic cleanup will not be performed until the file is removed.\n"
"\n"
"%s"
msgstr ""
+"Die letzte Ausführung von \"gc run\" enthielt die folgenden Meldungen.\n"
+"Bitte beheben Sie das Hauptproblem und löschen Sie %s.\n"
+"Ein automatisches Cleanup wird nicht ausgeführt, bis diese Datei entfernt\n"
+"wurde.\n"
+"\n"
+"%s"
#: builtin/gc.c:327
msgid "prune unreferenced objects"
msgstr "unreferenzierte Objekte entfernen"
#: builtin/gc.c:329
msgid "be more thorough (increased runtime)"
@@ -6664,17 +6652,16 @@ msgid ""
"git hash-object [-t <type>] [-w] [--path=<file> | --no-filters] [--stdin] "
"[--] <file>..."
msgstr ""
"git hash-object [-t <Art>] [-w] [--path=<Datei> | --no-filters] [--stdin] "
"[--] <Datei>..."
#: builtin/hash-object.c:81
-#, fuzzy
msgid "git hash-object --stdin-paths"
-msgstr "git hash-object --stdin-paths < <Liste-von-Pfaden>"
+msgstr "git hash-object --stdin-paths"
#: builtin/hash-object.c:92
msgid "type"
msgstr "Art"
#: builtin/hash-object.c:92
msgid "object type"
@@ -7397,15 +7384,15 @@ msgstr "[PATCH] nicht entfernen/hinzufügen"
#: builtin/log.c:1239
msgid "don't output binary diffs"
msgstr "keine binären Unterschiede ausgeben"
#: builtin/log.c:1241
msgid "output all-zero hash in From header"
-msgstr ""
+msgstr "Hash mit Nullen in \"From\"-Header ausgeben"
#: builtin/log.c:1243
msgid "don't include a patch matching a commit upstream"
msgstr ""
"keine Patches einschließen, die einem Commit im Upstream-Branch entsprechen"
#: builtin/log.c:1245
@@ -8825,20 +8812,18 @@ msgid "report pruned objects"
msgstr "gelöschte Objekte melden"
#: builtin/prune.c:109 builtin/worktree.c:127
msgid "expire objects older than <time>"
msgstr "Objekte älter als <Zeit> verfallen lassen"
#: builtin/prune.c:123
-#, fuzzy
msgid "cannot prune in a precious-objects repo"
-msgstr "Kann existierendes Objekt %s nicht lesen."
+msgstr "kann \"prune\" in precious-objects Repository nicht ausführen"
#: builtin/pull.c:69
-#, fuzzy
msgid "git pull [<options>] [<repository> [<refspec>...]]"
msgstr "git pull [<Optionen>] [<Repository> [<Refspec>...]]"
#: builtin/pull.c:113
msgid "Options related to merging"
msgstr "Optionen bezogen auf Merge"
@@ -9300,17 +9285,16 @@ msgid "refname>:<expect"
msgstr "Referenzname>:<Erwartungswert"
#: builtin/push.c:548 builtin/send-pack.c:176
msgid "require old value of ref to be at this value"
msgstr "Referenz muss sich auf dem angegebenen Wert befinden"
#: builtin/push.c:550
-#, fuzzy
msgid "check|on-demand|no"
-msgstr "bei-Bedarf"
+msgstr "check|on-demand|no"
#: builtin/push.c:551
msgid "control recursive pushing of submodules"
msgstr "rekursiven \"push\" von Submodulen steuern"
#: builtin/push.c:553 builtin/send-pack.c:169
msgid "use thin pack"
@@ -9477,17 +9461,16 @@ msgstr ""
"git remote [-v | --verbose] update [-p | --prune] [(<Gruppe> | <Remote>)...]"
#: builtin/remote.c:20
msgid "git remote set-branches [--add] <name> <branch>..."
msgstr "git remote set-branches [--add] <Name> <Branch>..."
#: builtin/remote.c:21 builtin/remote.c:70
-#, fuzzy
msgid "git remote get-url [--push] [--all] <name>"
-msgstr "git remote set-url [--push] <Name> <neueURL> [<alteURL>]"
+msgstr "git remote get-url [--push] [--all] <Name>"
#: builtin/remote.c:22 builtin/remote.c:75
msgid "git remote set-url [--push] <name> <newurl> [<oldurl>]"
msgstr "git remote set-url [--push] <Name> <neueURL> [<alteURL>]"
#: builtin/remote.c:23 builtin/remote.c:76
msgid "git remote set-url --add <name> <newurl>"
@@ -9903,24 +9886,24 @@ msgstr "Branch hinzufügen"
#: builtin/remote.c:1468
msgid "no remote specified"
msgstr "kein Remote-Repository angegeben"
#: builtin/remote.c:1485
msgid "query push URLs rather than fetch URLs"
-msgstr ""
+msgstr "nur URLs für Push ausgeben"
#: builtin/remote.c:1487
msgid "return all URLs"
-msgstr ""
+msgstr "alle URLs ausgeben"
#: builtin/remote.c:1515
-#, fuzzy, c-format
+#, c-format
msgid "no URLs configured for remote '%s'"
-msgstr "Kein Upstream-Branch für Branch '%s' konfiguriert."
+msgstr "Keine URLs für Remote-Repository '%s' konfiguriert."
#: builtin/remote.c:1541
msgid "manipulate push URLs"
msgstr "URLs für \"push\" manipulieren"
#: builtin/remote.c:1543
msgid "add URL"
@@ -10022,15 +10005,15 @@ msgstr "maximale Größe für jede Paketdatei"
#: builtin/repack.c:187
msgid "repack objects in packs marked with .keep"
msgstr ""
"Objekte umpacken, die sich in mit .keep markierten Pack-Dateien befinden"
#: builtin/repack.c:197
msgid "cannot delete packs in a precious-objects repo"
-msgstr ""
+msgstr "kann Pack-Dateien in precious-objects Repository nicht löschen"
#: builtin/repack.c:381
#, c-format
msgid "removing '%s' failed"
msgstr "Löschen von '%s' fehlgeschlagen"
#: builtin/replace.c:19
@@ -10628,17 +10611,16 @@ msgid ""
"git show-ref [-q | --quiet] [--verify] [--head] [-d | --dereference] [-s | --"
"hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<pattern>...]"
msgstr ""
"git show-ref [-q | --quiet] [--verify] [--head] [-d | --dereference] [-s | --"
"hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [<Muster>...] "
#: builtin/show-ref.c:11
-#, fuzzy
msgid "git show-ref --exclude-existing[=<pattern>]"
-msgstr "git show-ref --exclude-existing[=<Muster>] < <Referenzliste>"
+msgstr "git show-ref --exclude-existing[=<Muster>]"
#: builtin/show-ref.c:165
msgid "only show tags (can be combined with heads)"
msgstr "nur Tags anzeigen (kann mit \"heads\" kombiniert werden)"
#: builtin/show-ref.c:166
msgid "only show heads (can be combined with tags)"
@@ -10670,104 +10652,104 @@ msgstr ""
msgid "show refs from stdin that aren't in local repository"
msgstr ""
"Referenzen von der Standard-Eingabe anzeigen, die sich nicht im lokalen "
"Repository befinden"
#: builtin/stripspace.c:17
msgid "git stripspace [-s | --strip-comments]"
-msgstr ""
+msgstr "git stripspace [-s | --strip-comments]"
#: builtin/stripspace.c:18
msgid "git stripspace [-c | --comment-lines]"
-msgstr ""
+msgstr "git stripspace [-c | --comment-lines]"
#: builtin/stripspace.c:35
msgid "skip and remove all lines starting with comment character"
-msgstr ""
+msgstr "alle Zeilen, die mit dem Kommentarzeichen beginnen, überspringen und "
+"entfernen"
#: builtin/stripspace.c:38
msgid "prepend comment character and blank to each line"
-msgstr ""
+msgstr "Kommentarzeichen mit Leerzeichen an jeder Zeile voranstellen"
#: builtin/submodule--helper.c:79 builtin/submodule--helper.c:167
msgid "alternative anchor for relative paths"
-msgstr ""
+msgstr "Alternativer Anker für relative Pfade"
#: builtin/submodule--helper.c:84
msgid "git submodule--helper list [--prefix=<path>] [<path>...]"
-msgstr ""
+msgstr "git submodule--helper list [--prefix=<Pfad>] [<Pfad>...]"
#: builtin/submodule--helper.c:114
msgid "git submodule--helper name <path>"
-msgstr ""
+msgstr "git submodule--helper name <Pfad>"
#: builtin/submodule--helper.c:120
-#, fuzzy, c-format
+#, c-format
msgid "no submodule mapping found in .gitmodules for path '%s'"
-msgstr "Keine Submodul-Zuordnung in .gitmodules für Pfad '$sm_path' gefunden"
+msgstr "Keine Submodul-Zuordnung in .gitmodules für Pfad '%s' gefunden"
#: builtin/submodule--helper.c:170
msgid "where the new submodule will be cloned to"
-msgstr ""
+msgstr "Pfad für neues Submodul"
#: builtin/submodule--helper.c:173
-#, fuzzy
msgid "name of the new submodule"
-msgstr "Aktualisierung: ignoriert Submodule"
+msgstr "Name des neuen Submoduls"
#: builtin/submodule--helper.c:176
msgid "url where to clone the submodule from"
-msgstr ""
+msgstr "URL von der das Submodul geklont wird"
#: builtin/submodule--helper.c:182
-#, fuzzy
msgid "depth for shallow clones"
-msgstr ""
-"die Historie eines Klons mit unvollständiger Historie (shallow) vertiefen"
+msgstr "Tiefe des Klons mit unvollständiger Historie (shallow)"
#: builtin/submodule--helper.c:188
msgid ""
"git submodule--helper clone [--prefix=<path>] [--quiet] [--reference "
"<repository>] [--name <name>] [--url <url>][--depth <depth>] [--] [<path>...]"
msgstr ""
+"git submodule--helper clone [--prefix=<Pfad>] [--quiet] [--reference "
+"<Repository>] [--name <Name>] [--url <URL>][--depth <Tiefe>] [--] [<Pfad>...]"
#: builtin/submodule--helper.c:202 builtin/submodule--helper.c:208
#: builtin/submodule--helper.c:216
-#, fuzzy, c-format
+#, c-format
msgid "could not create directory '%s'"
msgstr "Konnte Verzeichnis '%s' nicht erstellen."
#: builtin/submodule--helper.c:204
-#, fuzzy, c-format
+#, c-format
msgid "clone of '%s' into submodule path '%s' failed"
-msgstr "Klonen von '$url' in Submodul-Pfad '$sm_path' fehlgeschlagen"
+msgstr "Klonen von '%s' in Submodul-Pfad '%s' fehlgeschlagen"
#: builtin/submodule--helper.c:227
-#, fuzzy, c-format
+#, c-format
msgid "cannot open file '%s'"
-msgstr "Kann Paketdatei '%s' nicht öffnen"
+msgstr "Kann Datei '%s' nicht öffnen"
#: builtin/submodule--helper.c:232
-#, fuzzy, c-format
+#, c-format
msgid "could not close file %s"
-msgstr "Konnte '%s' nicht schließen."
+msgstr "Konnte Datei '%s' nicht schließen."
#: builtin/submodule--helper.c:247
-#, fuzzy, c-format
+#, c-format
msgid "could not get submodule directory for '%s'"
-msgstr "Konnte Verzeichnis '%s' nicht erstellen."
+msgstr "Konnte Submodul-Verzeichnis '%s' nicht finden."
#: builtin/submodule--helper.c:273
msgid "fatal: submodule--helper subcommand must be called with a subcommand"
-msgstr ""
+msgstr "fatal: submodule-helper muss mit einem Unterkommando aufgerufen werden"
#: builtin/submodule--helper.c:280
#, c-format
msgid "fatal: '%s' is not a valid submodule--helper subcommand"
-msgstr ""
+msgstr "fatal: '%s' ist kein gültiges Unterkommando von submodule-helper"
#: builtin/symbolic-ref.c:7
msgid "git symbolic-ref [<options>] <name> [<ref>]"
msgstr "git symbolic-ref [<Optionen>] <Name> [<Referenz>]"
#: builtin/symbolic-ref.c:8
msgid "git symbolic-ref -d [-q] <name>"
@@ -10803,21 +10785,20 @@ msgstr ""
"<Tagname> [<Commit>]"
#: builtin/tag.c:24
msgid "git tag -d <tagname>..."
msgstr "git tag -d <Tagname>..."
#: builtin/tag.c:25
-#, fuzzy
msgid ""
"git tag -l [-n[<num>]] [--contains <commit>] [--points-at <object>]\n"
"\t\t[--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]"
msgstr ""
"git tag -l [-n[<Nummer>]] [--contains <Commit>] [--points-at <Objekt>]\n"
-"\t\t[<Muster>...]"
+"\t\t[--format=<Muster>] [--[no-]merged [<Commit>]] [Muster>...]"
#: builtin/tag.c:27
msgid "git tag -v <tagname>..."
msgstr "git tag -v <Tagname>..."
#: builtin/tag.c:80
#, c-format
@@ -10945,22 +10926,20 @@ msgid "show tag list in columns"
msgstr "Liste der Tags in Spalten anzeigen"
#: builtin/tag.c:362 builtin/tag.c:363
msgid "print only tags that contain the commit"
msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
#: builtin/tag.c:364
-#, fuzzy
msgid "print only tags that are merged"
-msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
+msgstr "nur Tags ausgeben, die gemerged wurden"
#: builtin/tag.c:365
-#, fuzzy
msgid "print only tags that are not merged"
-msgstr "nur Tags ausgeben, die diesen Commit beinhalten"
+msgstr "nur Tags ausgeben, die nicht gemerged wurden"
#: builtin/tag.c:370
msgid "print only tags of the object"
msgstr "nur Tags von dem Objekt ausgeben"
#: builtin/tag.c:399
msgid "--column and -n are incompatible"
@@ -10975,17 +10954,16 @@ msgid "--contains option is only allowed with -l."
msgstr "--contains Option ist nur erlaubt mit -l."
#: builtin/tag.c:423
msgid "--points-at option is only allowed with -l."
msgstr "--points-at Option ist nur erlaubt mit -l."
#: builtin/tag.c:425
-#, fuzzy
msgid "--merged and --no-merged option are only allowed with -l"
-msgstr "-n Option ist nur erlaubt mit -l."
+msgstr "Die Optionen --merged und --no-merged sind nur mit -l erlaubt."
#: builtin/tag.c:433
msgid "only one -F or -m option is allowed."
msgstr "nur eine -F oder -m Option ist erlaubt."
#: builtin/tag.c:453
msgid "too many params"
@@ -11276,26 +11254,24 @@ msgid "git verify-tag [-v | --verbose] <tag>..."
msgstr "git verify-tag [-v | --verbose] <Tag>..."
#: builtin/verify-tag.c:83
msgid "print tag contents"
msgstr "Tag-Inhalte ausgeben"
#: builtin/worktree.c:15
-#, fuzzy
msgid "git worktree add [<options>] <path> [<branch>]"
-msgstr "git worktree add [<Optionen>] <Pfad> <Branch>"
+msgstr "git worktree add [<Optionen>] <Pfad> [<Branch>]"
#: builtin/worktree.c:16
msgid "git worktree prune [<options>]"
msgstr "git worktree prune [<Optionen>]"
#: builtin/worktree.c:17
-#, fuzzy
msgid "git worktree list [<options>]"
-msgstr "git worktree prune [<Optionen>]"
+msgstr "git worktree list [<Optionen>]"
#: builtin/worktree.c:39
#, c-format
msgid "Removing worktrees/%s: not a valid directory"
msgstr "Lösche worktrees/%s: kein gültiges Verzeichnis"
#: builtin/worktree.c:45
@@ -11692,48 +11668,50 @@ msgstr ""
#: git-bisect.sh:538
msgid "bisect run success"
msgstr "'bisect run' erfolgreich ausgeführt"
#: git-bisect.sh:565
msgid "please use two different terms"
-msgstr ""
+msgstr "Bitte verwenden Sie zwei verschiedene Begriffe."
#: git-bisect.sh:575
-#, fuzzy, sh-format
+#, sh-format
msgid "'$term' is not a valid term"
-msgstr "'%s' ist kein gültiger Zeitstempel"
+msgstr "'$term' ist kein gültiger Begriff"
#: git-bisect.sh:578
#, sh-format
msgid "can't use the builtin command '$term' as a term"
-msgstr ""
+msgstr "Kann eingebautes Kommando '$term' nicht als Begriff verwenden"
#: git-bisect.sh:587 git-bisect.sh:593
#, sh-format
msgid "can't change the meaning of term '$term'"
-msgstr ""
+msgstr "Kann Bedeutung von '$term' nicht ändern."
#: git-bisect.sh:606
#, sh-format
msgid "Invalid command: you're currently in a $TERM_BAD/$TERM_GOOD bisect."
msgstr ""
"Ungültiges Kommando: Sie sind gerade bei einer binären $TERM_BAD/$TERM_GOOD "
"Suche."
#: git-bisect.sh:636
msgid "no terms defined"
-msgstr ""
+msgstr "Keine Begriffe definiert."
#: git-bisect.sh:653
#, sh-format
msgid ""
"invalid argument $arg for 'git bisect terms'.\n"
"Supported options are: --term-good|--term-old and --term-bad|--term-new."
msgstr ""
+"Ungültiges Argument $arg für 'git bisect terms'.\n"
+"Unterstützte Optionen sind: --term-good|--term-old und --term-bad|--term-new."
#: git-rebase.sh:57
msgid ""
"When you have resolved this problem, run \"git rebase --continue\".\n"
"If you prefer to skip this patch, run \"git rebase --skip\" instead.\n"
"To check out the original branch and stop rebasing, run \"git rebase --abort"
"\"."
--
2.7.0.rc1.195.g5ee9e94
^ permalink raw reply related [relevance 5%]
* [PATCHv2 01/56] t6042: Add a testcase where git deletes an untracked file
@ 2011-08-12 5:19 5% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
Current git will nuke an untracked file during a rename/delete conflict if
(a) there is an untracked file whose name matches the source of a rename
and (b) the merge is done in a certain direction. Add a simple testcase
demonstrating this bug.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
No changes since v1.
t/t6036-recursive-corner-cases.sh | 2 +-
t/t6042-merge-rename-corner-cases.sh | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletions(-)
create mode 100755 t/t6042-merge-rename-corner-cases.sh
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 871577d..319b6fa 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='recursive merge corner cases'
+test_description='recursive merge corner cases involving criss-cross merges'
. ./test-lib.sh
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
new file mode 100755
index 0000000..5054459
--- /dev/null
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+test_description="recursive merge corner cases w/ renames but not criss-crosses"
+# t6036 has corner cases that involve both criss-cross merges and renames
+
+. ./test-lib.sh
+
+test_expect_success 'setup rename/delete + untracked file' '
+ echo "A pretty inscription" >ring &&
+ git add ring &&
+ test_tick &&
+ git commit -m beginning &&
+
+ git branch people &&
+ git checkout -b rename-the-ring &&
+ git mv ring one-ring-to-rule-them-all &&
+ test_tick &&
+ git commit -m fullname &&
+
+ git checkout people &&
+ git rm ring &&
+ echo gollum >owner &&
+ git add owner &&
+ test_tick &&
+ git commit -m track-people-instead-of-objects &&
+ echo "Myyy PRECIOUSSS" >ring
+'
+
+test_expect_failure "Does git preserve Gollum's precious artifact?" '
+ test_must_fail git merge -s recursive rename-the-ring &&
+
+ # Make sure git did not delete an untracked file
+ test -f ring
+'
+
+test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related [relevance 5%]
* [PATCH v3 13/22] worktree: make --detach mutually exclusive with -b/-B
@ 2015-07-17 23:00 5% ` Eric Sunshine
2015-07-17 23:00 5% ` [PATCH v3 14/22] worktree: add: suppress auto-vivication with --detach and no <branch> Eric Sunshine
1 sibling, 0 replies; 200+ results
From: Eric Sunshine @ 2015-07-17 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Duy Nguyen, Michael J Gruber, Eric Sunshine
Be consistent with git-checkout which disallows this (not particularly
meaningful) combination.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
Changes since v2: add tests
builtin/worktree.c | 4 ++--
t/t2025-worktree-add.sh | 12 ++++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7d70eb6..813e016 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -296,8 +296,8 @@ static int add(int ac, const char **av, const char *prefix)
memset(&opts, 0, sizeof(opts));
ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
- if (opts.new_branch && new_branch_force)
- die(_("-b and -B are mutually exclusive"));
+ if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
+ die(_("-b, -B, and --detach are mutually exclusive"));
if (ac < 1 || ac > 2)
usage_with_options(worktree_usage, options);
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 9e30690..249e454 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -167,4 +167,16 @@ test_expect_success '"add" auto-vivify does not clobber existing branch' '
test_path_is_missing precious
'
+test_expect_success '"add" -b/-B mutually exclusive' '
+ test_must_fail git worktree add -b poodle -B poodle bamboo master
+'
+
+test_expect_success '"add" -b/--detach mutually exclusive' '
+ test_must_fail git worktree add -b poodle --detach bamboo master
+'
+
+test_expect_success '"add" -B/--detach mutually exclusive' '
+ test_must_fail git worktree add -B poodle --detach bamboo master
+'
+
test_done
--
2.5.0.rc2.378.g0af52e8
^ permalink raw reply related [relevance 5%]
* [PATCH 01/48] t6039: Add a testcase where git deletes an untracked file
@ 2011-06-08 7:30 5% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2011-06-08 7:30 UTC (permalink / raw)
To: git; +Cc: jgfouca, Elijah Newren
Current git will nuke an untracked file during a rename/delete conflict if
(a) there is an untracked file whose name matches the source of a rename
and (b) the merge is done in a certain direction. Add a simple testcase
demonstrating this bug.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t/t6036-recursive-corner-cases.sh | 2 +-
t/t6039-merge-rename-corner-cases.sh | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletions(-)
create mode 100755 t/t6039-merge-rename-corner-cases.sh
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 871577d..319b6fa 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='recursive merge corner cases'
+test_description='recursive merge corner cases involving criss-cross merges'
. ./test-lib.sh
diff --git a/t/t6039-merge-rename-corner-cases.sh b/t/t6039-merge-rename-corner-cases.sh
new file mode 100755
index 0000000..5054459
--- /dev/null
+++ b/t/t6039-merge-rename-corner-cases.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+test_description="recursive merge corner cases w/ renames but not criss-crosses"
+# t6036 has corner cases that involve both criss-cross merges and renames
+
+. ./test-lib.sh
+
+test_expect_success 'setup rename/delete + untracked file' '
+ echo "A pretty inscription" >ring &&
+ git add ring &&
+ test_tick &&
+ git commit -m beginning &&
+
+ git branch people &&
+ git checkout -b rename-the-ring &&
+ git mv ring one-ring-to-rule-them-all &&
+ test_tick &&
+ git commit -m fullname &&
+
+ git checkout people &&
+ git rm ring &&
+ echo gollum >owner &&
+ git add owner &&
+ test_tick &&
+ git commit -m track-people-instead-of-objects &&
+ echo "Myyy PRECIOUSSS" >ring
+'
+
+test_expect_failure "Does git preserve Gollum's precious artifact?" '
+ test_must_fail git merge -s recursive rename-the-ring &&
+
+ # Make sure git did not delete an untracked file
+ test -f ring
+'
+
+test_done
--
1.7.6.rc0.62.g2d69f
^ permalink raw reply related [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
2018-11-12 23:22 5% ` brian m. carlson
@ 2018-11-26 9:30 5% ` Per Lundberg
2018-11-26 10:28 5% ` Ævar Arnfjörð Bjarmason
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Per Lundberg @ 2018-11-26 9:30 UTC (permalink / raw)
To: brian m. carlson, git@vger.kernel.org, Steffen Jost,
Joshua Jensen, Junio C Hamano, Matthieu Moy, Clemens Buchacher,
Holger Hellmuth, Kevin Ballard
Cc: Ævar Arnfjörð Bjarmason,
Nguyễn Thái Ngọc Duy
On 11/13/18 1:22 AM, brian m. carlson wrote:
> This is going to totally hose automation. My last job had files which
> might move from tracked to untracked (a file that had become generated),
> and long-running CI and build systems would need to be able to check out
> one status and switch to the other. Your proposed change will prevent
> those systems from working, whereas they previously did.
>
> I agree that your proposal would have been a better design originally,
> but breaking the way automated systems currently work is probably going
> to be a dealbreaker.
How about something like this:
1. Introduce a concept with "garbage" files, which git is "permitted to
delete" without prompting.
2. Retain the current default, i.e. "ignored files are garbage" for now,
making the new behavior _opt in_ to avoid breaking automated
systems/existing scripts for anyone. Put the setting for this behind a
new core.* config flag.
3. In the plan for version 3.0 (a new major version where some breakage
can be tolerable, according to Semantic Versioning), change the default
so that "only explicit garbage is garbage". Include very clear notices
of this in the release notes. The config flag is retained, but its
default changes from true->false or vice versa. People who dislike the
new behavior can easily change back to the 2.x semantics.
Would this be a reasonable compromise for everybody?
--
Per Lundberg
^ permalink raw reply [relevance 5%]
* [PATCH] Makefile: drop extra dependencies for test helpers
@ 2016-07-01 7:56 5% Jeff King
2016-07-01 7:59 5% ` [PATCH] Makefile: use VCSSVN_LIB to refer to svn library Jeff King
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2016-07-01 7:56 UTC (permalink / raw)
To: git
A few test-helpers have Makefile dependencies on specific
object files. But since these files are part of libgit.a
(which all of the helpers link against), the inclusion is
simply redundant.
These were once necessary, but became redundant due to
5c5ba73 (Makefile: Use generic rule to build test programs,
2007-05-31), which added the $(GITLIBS) dependency (but
didn't prune the extra dependency lines). Later commits then
cargo-culted the practice (e.g., b4285c7).
Note that we _do_ need to leave the dependencies on the svn
library, as that is not part of the usual link command.
Signed-off-by: Jeff King <peff@peff.net>
---
Just a cleanup I noticed while working on the common-main series.
Makefile | 8 --------
1 file changed, 8 deletions(-)
diff --git a/Makefile b/Makefile
index de5a030..22815a2 100644
--- a/Makefile
+++ b/Makefile
@@ -2225,16 +2225,8 @@ perf: all
.PHONY: test perf
-t/helper/test-ctype$X: ctype.o
-
-t/helper/test-date$X: date.o ctype.o
-
-t/helper/test-delta$X: diff-delta.o patch-delta.o
-
t/helper/test-line-buffer$X: vcs-svn/lib.a
-t/helper/test-parse-options$X: parse-options.o parse-options-cb.o
-
t/helper/test-svn-fe$X: vcs-svn/lib.a
.PRECIOUS: $(TEST_OBJS)
--
2.9.0.317.g65b4e7c
^ permalink raw reply related [relevance 5%]
* [PATCH 2/7] repack: use die_for_incompatible_opt3() for -A/-k/--cruft
@ 2023-12-06 11:51 5% ` René Scharfe
0 siblings, 0 replies; 200+ results
From: René Scharfe @ 2023-12-06 11:51 UTC (permalink / raw)
To: git
The repack option --keep-unreachable is incompatible with -A, --cruft is
incompatible with -A and -k, and -k is short for --keep-unreachable. So
they are all incompatible with each other.
Use the function for checking three mutually incompatible options,
die_for_incompatible_opt3(), to perform this check in one place and
without repetition. This is shorter and clearer.
Signed-off-by: René Scharfe <l.s.r@web.de>
---
builtin/repack.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index edaee4dbec..c54777bbe5 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -1203,19 +1203,13 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
if (delete_redundant && repository_format_precious_objects)
die(_("cannot delete packs in a precious-objects repo"));
- if (keep_unreachable &&
- (unpack_unreachable || (pack_everything & LOOSEN_UNREACHABLE)))
- die(_("options '%s' and '%s' cannot be used together"), "--keep-unreachable", "-A");
+ die_for_incompatible_opt3(unpack_unreachable || (pack_everything & LOOSEN_UNREACHABLE), "-A",
+ keep_unreachable, "-k/--keep-unreachable",
+ pack_everything & PACK_CRUFT, "--cruft");
- if (pack_everything & PACK_CRUFT) {
+ if (pack_everything & PACK_CRUFT)
pack_everything |= ALL_INTO_ONE;
- if (unpack_unreachable || (pack_everything & LOOSEN_UNREACHABLE))
- die(_("options '%s' and '%s' cannot be used together"), "--cruft", "-A");
- if (keep_unreachable)
- die(_("options '%s' and '%s' cannot be used together"), "--cruft", "-k");
- }
-
if (write_bitmaps < 0) {
if (!write_midx &&
(!(pack_everything & ALL_INTO_ONE) || !is_bare_repository()))
--
2.43.0
^ permalink raw reply related [relevance 5%]
* [PATCH v2 2/3] t4151: add a few am --abort tests
@ 2021-09-10 10:31 5% ` Elijah Newren via GitGitGadget
0 siblings, 0 replies; 200+ results
From: Elijah Newren via GitGitGadget @ 2021-09-10 10:31 UTC (permalink / raw)
To: git
Cc: Bagas Sanjaya, Elijah Newren, Johannes Schindelin, Elijah Newren,
Elijah Newren
From: Elijah Newren <newren@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t/t4151-am-abort.sh | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 9d8d3c72e7e..15f2f92cd76 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -23,7 +23,13 @@ test_expect_success setup '
test_tick &&
git commit -a -m $i || return 1
done &&
+ git branch changes &&
git format-patch --no-numbered initial &&
+ git checkout -b conflicting initial &&
+ echo different >>file-1 &&
+ echo whatever >new-file &&
+ git add file-1 new-file &&
+ git commit -m different &&
git checkout -b side initial &&
echo local change >file-2-expect
'
@@ -191,4 +197,37 @@ test_expect_success 'am --abort leaves index stat info alone' '
git diff-files --exit-code --quiet
'
+test_expect_failure 'git am --abort return failed exit status when it fails' '
+ test_when_finished "rm -rf file-2/ && git reset --hard && git am --abort" &&
+ git checkout changes &&
+ git format-patch -1 --stdout conflicting >changes.mbox &&
+ test_must_fail git am --3way changes.mbox &&
+
+ git rm file-2 &&
+ mkdir file-2 &&
+ echo precious >file-2/somefile &&
+ test_must_fail git am --abort &&
+ test_path_is_dir file-2/
+'
+
+test_expect_success 'git am --abort cleans relevant files' '
+ git checkout changes &&
+ git format-patch -1 --stdout conflicting >changes.mbox &&
+ test_must_fail git am --3way changes.mbox &&
+
+ test_path_is_file new-file &&
+ echo further changes >>file-1 &&
+ echo change other file >>file-2 &&
+
+ # Abort, and expect the files touched by am to be reverted
+ git am --abort &&
+
+ test_path_is_missing new-file &&
+
+ # Files not involved in am operation are left modified
+ git diff --name-only changes >actual &&
+ test_write_lines file-2 >expect &&
+ test_cmp expect actual
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related [relevance 5%]
* [PATCH 3/4] Generate PDF documents using docbook2pdf
2006-03-10 14:43 5% ` [PATCH 2/4] Encode the manpage section in the file name Jonas Fonseca
@ 2006-03-10 14:44 5% ` Jonas Fonseca
1 sibling, 0 replies; 200+ results
From: Jonas Fonseca @ 2006-03-10 14:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Unfortunately xmlto cannot be used for this,
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/Makefile | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 00e9276..d316a14 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -11,6 +11,8 @@ DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_
DOC_MAN1=$(patsubst %.txt,%,$(MAN1_TXT))
DOC_MAN7=$(patsubst %.txt,%,$(MAN7_TXT))
+DOC_PDF=$(patsubst %.txt,%.pdf,$(MAN1_TXT) $(MAN7_TXT)) introduction.pdf
+
prefix=$(HOME)
bin=$(prefix)/bin
mandir=$(prefix)/man
@@ -35,15 +37,17 @@ all: html man txt
html: $(DOC_HTML)
-
man: man1 man7
man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
+pdf: $(DOC_PDF)
+
txt: txt1 txt7
txt1: $(MAN1_TXT)
txt7: $(MAN7_TXT)
+
install: man txt
$(INSTALL) -m755 -d $(DESTDIR)/$(txtdir)
$(INSTALL) $(MAN1_TXT) $(MAN7_TXT) $(DESTDIR)/$(txtdir)
@@ -56,13 +60,16 @@ install-html: html
$(INSTALL) $(DOC_HTML) $(DESTDIR)/$(htmldir)
clean:
- rm -f *.xml *.html *.1 *.7 cg*.[17].txt $(PACKAGE).7.txt
+ rm -f *.xml *.html *.pdf *.1 *.7 cg*.[17].txt $(PACKAGE).7.txt
.PRECIOUS: cg%.txt
introduction.html: ../README
asciidoc -b xhtml11 -d article -f asciidoc.conf -o $@ $<
+introduction.xml: ../README
+ asciidoc -b docbook -d article -f asciidoc.conf -o $@ $<
+
%.1.html : %.1.txt
asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
@@ -87,6 +94,9 @@ introduction.html: ../README
%.7 : %.7.xml
xmlto man $<
+%.pdf : %.xml
+ docbook2pdf $<
+
$(PACKAGE).7.txt : make-$(PACKAGE)-asciidoc
./make-$(PACKAGE)-asciidoc > $@
--
Jonas Fonseca
^ permalink raw reply related [relevance 5%]
* [PATCH 3/6] i18n win32: add git-pull eval_gettext variable prefix
@ 2011-05-25 23:19 5% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2011-05-25 23:19 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jonathan Nieder, Johannes Sixt,
Ævar Arnfjörð Bjarmason
Change the eval_gettext() invocations to use the GIT_I18N_VARIABLE_
prefix for variables used in eval_gettext. On Windows environment
variables are case insensitive, so e.g. $PATH clashes with $path. By
using a sufficiently unique prefix we work around that issue.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
git-pull.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index a10b129..d5f25a6 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -217,17 +217,18 @@ then
# $orig_head commit, but we are merging into $curr_head.
# First update the working tree to match $curr_head.
+ GIT_I18N_VARIABLE_orig_head=$orig_head
(
eval_gettext "Warning: fetch updated the current branch head.
Warning: fast-forwarding your working tree from
-Warning: commit \$orig_head." &&
+Warning: commit \$GIT_I18N_VARIABLE_orig_head." &&
echo
) >&2
git update-index -q --refresh
git read-tree -u -m "$orig_head" "$curr_head" ||
die "$(eval_gettext "Cannot fast-forward your working tree.
After making sure that you saved anything precious from
-$ git diff \$orig_head
+$ git diff \$GIT_I18N_VARIABLE_orig_head
output, run
$ git reset --hard
to recover.")"
--
1.7.5.1
^ permalink raw reply related [relevance 5%]
* Re: [PATCH 1/1] Introduce "precious" file concept
2019-02-17 9:31 5% ` Duy Nguyen
@ 2019-02-18 9:53 5% ` Ævar Arnfjörð Bjarmason
1 sibling, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2019-02-18 9:53 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano, Per Lundberg, Steffen Jost,
Joshua Jensen, Matthieu Moy, Clemens Buchacher, Holger Hellmuth,
Kevin Ballard
On Sun, Feb 17 2019, Duy Nguyen wrote:
> On Sun, Feb 17, 2019 at 2:36 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>>
>>
>> On Sat, Feb 16 2019, Nguyễn Thái Ngọc Duy wrote:
>>
>> [Re-CC some people involved the last time around]
>>
>> > A new attribute "precious" is added to indicate that certain files
>> > have valuable content and should not be easily discarded even if they
>> > are ignored or untracked.
>> >
>> > So far there are one part of Git that are made aware of precious
>> > files: "git clean" will leave precious files alone.
>>
>> Thanks for bringing this up again. There were also some patches recently
>> to save away clobbered files, do you/anyone else have any end goal in
>> mind here that combines this & that, or some other thing I may not have
>> kept up with?
>
> I assume you mean the clobbering untracked files by merge/checkout.
> Those files will be backed up [1] if backup-log is implemented. Even
> files deleted by "git clean" could be saved but that might go a little
> too far.
And I suppose if we have some mechanism for "don't backup but error out
if it was detectes as needed" we'll have the equivalent of inverting the
merge/checkout --force behavior now (& my "garbage" patch), i.e. we'd
stall on potential clobbering and need to carry on with --force.
> [1] https://public-inbox.org/git/20181209104419.12639-20-pclouds@gmail.com/
>
>> My commentary on this whole thing is basically a repeat of what I said
>> in https://public-inbox.org/git/87wop0yvxv.fsf@evledraar.gmail.com/
>>
>> I.e. we have a definite problem here somewhere, and there is some
>> solution, but this patch feels a bit like navigating that maze in the
>> dark without a map.
>>
>> We had users report that the likes of "pull" were eating their data, but
>> now with this iteration of "precious" only impacting "clean" the only
>> problem anyone with the current semantics is still left unaddressed. My
>> memory (I may be wrong) is that "clean" was just brought up (by you?) as
>> a "what about this other related case?" in that whole discussion.
>>
>> So as noted in the E-Mail linked above I think the first step should be
>> to enumerate/document/test the cases where we're now eating data
>> implicitly, and discuss how that relates to the semantics we desired
>> when the data-eating behavior was first introduced (as noted in E-Mails
>> linked from the above, my own preliminary digging seems to reveal there
>> isn't much of a relationship between the two).
>>
>> Only when we have that list of XYZ cases we're supporting now, and can
>> see that XYZ is so important to maintain backwards compatibility for
>> that we can't change it should way say "we eat your data by default
>> because XYZ is so useful/backcompat, set 'precious' ...".
>>
>> But right now we don't even have the list of XYZ or tests for them (as
>> my RFC "garbage" attribute patch revealed). So this whole thing still
>> feels like jumping three steps ahead to me in terms of addressing *that*
>> issue, but perhaps you have some orthogonal use-case in mind for this?
>
> I'm not addressing the accidentally losing data in this patch. My
> answer for that would still be backup-log, if it ever gets merged. But
> this patch is about _known_ files that I want to keep when doing "git
> clean", no more.
Indeed. My concern is that we're making incremental steps without a
clear idea of the end state, and once we get there we might find that
some steps along the way box us in or weren't what we wanted to solve
the overall UX issue.
More so in the CL / commit message not describing where we are overall,
where this patch fits in (backup log, etc.) than this whole thing
(backup log is already 24 patches) needing to be sent as one giant
series...
^ permalink raw reply [relevance 5%]
* Re: [PATCH] Introduce "precious" file concept
@ 2019-04-12 1:28 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2019-04-12 1:28 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Ævar Arnfjörð Bjarmason, Git Mailing List
Duy Nguyen <pclouds@gmail.com> writes:
> But gitattributes.txt explicitly says that it's wrong. One would need
> to do "path/** precious" to achieve the same thing.
>
> So yeah maybe doing this before S_ISDIR() is wrong. The definition of
> `precious` also only says "... is set on _files_". Maybe best to
> ignore attributes on directories? At least it looks like that's how
> all other attributes do.
I could be persuaded in the other direction if there are widespread
uses (or misuses---but once it gets widespread in the wild and turns
out to be useful, it ceases to be misuses and becomes a feature) of
giving an attribute to a directory that affects the treatment of
that directory *itself*, but if there is none, I'd prefer to keep
the attribute "what's tracked only".
Whether it is a good idea to give an attribute to a directory to
affect the treatement of the directory *itself* (eh, rather,
especially if it were a good idea), I'd consider it a misuse as a
short-hand for giving all paths within it the same attribute, given
"path/**" is available, as that would make it impossible to say "I'd
want to affect this directory, but not any of the directories or
files in it".
And if that is not clear in the current documentation set that faces
our developers, perhaps we should make it so.
Thanks.
^ permalink raw reply [relevance 5%]
* [PATCH v2 12/19] pull: fast-forward working tree if head is updated
@ 2015-06-03 6:48 5% ` Paul Tan
0 siblings, 0 replies; 200+ results
From: Paul Tan @ 2015-06-03 6:48 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Johannes Schindelin, Stephen Robin, Paul Tan
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
---
builtin/pull.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index 703fc1d..8db0db2 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -411,6 +411,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
{
const char *repo, **refspecs;
struct sha1_array merge_heads = SHA1_ARRAY_INIT;
+ unsigned char orig_head[GIT_SHA1_RAWSZ], curr_head[GIT_SHA1_RAWSZ];
if (!getenv("_GIT_USE_BUILTIN_PULL")) {
const char *path = mkpath("%s/git-pull", git_exec_path());
@@ -434,12 +435,41 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
if (!opt_ff.len)
config_get_ff(&opt_ff);
+ if (get_sha1("HEAD", orig_head))
+ hashclr(orig_head);
+
if (run_fetch(repo, refspecs))
return 1;
if (opt_dry_run)
return 0;
+ if (get_sha1("HEAD", curr_head))
+ hashclr(curr_head);
+
+ if (!is_null_sha1(orig_head) && !is_null_sha1(curr_head) &&
+ hashcmp(orig_head, curr_head)) {
+ /*
+ * The fetch involved updating the current branch.
+ *
+ * The working tree and the index file are still based on
+ * orig_head commit, but we are merging into curr_head.
+ * Update the working tree to match curr_head.
+ */
+
+ warning(_("fetch updated the current branch head.\n"
+ "fast-forwarding your working tree from\n"
+ "commit %s."), sha1_to_hex(orig_head));
+
+ if (checkout_fast_forward(orig_head, curr_head, 0))
+ die(_("Cannot fast-forward your working tree.\n"
+ "After making sure that you saved anything precious from\n"
+ "$ git diff %s\n"
+ "output, run\n"
+ "$ git reset --hard\n"
+ "to recover."), sha1_to_hex(orig_head));
+ }
+
get_merge_heads(&merge_heads);
if (!merge_heads.nr)
--
2.1.4
^ permalink raw reply related [relevance 5%]
* [PATCH v3 12/19] pull: fast-forward working tree if head is updated
@ 2015-06-14 8:41 5% ` Paul Tan
0 siblings, 0 replies; 200+ results
From: Paul Tan @ 2015-06-14 8:41 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Stefan Beller, Stephen Robin, Paul Tan
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
---
builtin/pull.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index cb5898a..0e48a14 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -412,6 +412,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
{
const char *repo, **refspecs;
struct sha1_array merge_heads = SHA1_ARRAY_INIT;
+ unsigned char orig_head[GIT_SHA1_RAWSZ], curr_head[GIT_SHA1_RAWSZ];
if (!getenv("_GIT_USE_BUILTIN_PULL")) {
const char *path = mkpath("%s/git-pull", git_exec_path());
@@ -435,12 +436,41 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
if (file_exists(git_path("MERGE_HEAD")))
die_conclude_merge();
+ if (get_sha1("HEAD", orig_head))
+ hashclr(orig_head);
+
if (run_fetch(repo, refspecs))
return 1;
if (opt_dry_run)
return 0;
+ if (get_sha1("HEAD", curr_head))
+ hashclr(curr_head);
+
+ if (!is_null_sha1(orig_head) && !is_null_sha1(curr_head) &&
+ hashcmp(orig_head, curr_head)) {
+ /*
+ * The fetch involved updating the current branch.
+ *
+ * The working tree and the index file are still based on
+ * orig_head commit, but we are merging into curr_head.
+ * Update the working tree to match curr_head.
+ */
+
+ warning(_("fetch updated the current branch head.\n"
+ "fast-forwarding your working tree from\n"
+ "commit %s."), sha1_to_hex(orig_head));
+
+ if (checkout_fast_forward(orig_head, curr_head, 0))
+ die(_("Cannot fast-forward your working tree.\n"
+ "After making sure that you saved anything precious from\n"
+ "$ git diff %s\n"
+ "output, run\n"
+ "$ git reset --hard\n"
+ "to recover."), sha1_to_hex(orig_head));
+ }
+
get_merge_heads(&merge_heads);
if (!merge_heads.nr)
--
2.1.4
^ permalink raw reply related [relevance 5%]
* [PATCH v4 12/19] pull: fast-forward working tree if head is updated
@ 2015-06-18 10:54 5% ` Paul Tan
0 siblings, 0 replies; 200+ results
From: Paul Tan @ 2015-06-18 10:54 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Johannes Schindelin, Stephen Robin, Paul Tan
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan <pyokagan@gmail.com>
---
builtin/pull.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/builtin/pull.c b/builtin/pull.c
index 1e688be..110e719 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -412,6 +412,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
{
const char *repo, **refspecs;
struct sha1_array merge_heads = SHA1_ARRAY_INIT;
+ unsigned char orig_head[GIT_SHA1_RAWSZ], curr_head[GIT_SHA1_RAWSZ];
if (!getenv("_GIT_USE_BUILTIN_PULL")) {
const char *path = mkpath("%s/git-pull", git_exec_path());
@@ -435,12 +436,41 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
if (file_exists(git_path("MERGE_HEAD")))
die_conclude_merge();
+ if (get_sha1("HEAD", orig_head))
+ hashclr(orig_head);
+
if (run_fetch(repo, refspecs))
return 1;
if (opt_dry_run)
return 0;
+ if (get_sha1("HEAD", curr_head))
+ hashclr(curr_head);
+
+ if (!is_null_sha1(orig_head) && !is_null_sha1(curr_head) &&
+ hashcmp(orig_head, curr_head)) {
+ /*
+ * The fetch involved updating the current branch.
+ *
+ * The working tree and the index file are still based on
+ * orig_head commit, but we are merging into curr_head.
+ * Update the working tree to match curr_head.
+ */
+
+ warning(_("fetch updated the current branch head.\n"
+ "fast-forwarding your working tree from\n"
+ "commit %s."), sha1_to_hex(orig_head));
+
+ if (checkout_fast_forward(orig_head, curr_head, 0))
+ die(_("Cannot fast-forward your working tree.\n"
+ "After making sure that you saved anything precious from\n"
+ "$ git diff %s\n"
+ "output, run\n"
+ "$ git reset --hard\n"
+ "to recover."), sha1_to_hex(orig_head));
+ }
+
get_merge_heads(&merge_heads);
if (!merge_heads.nr)
--
2.1.4
^ permalink raw reply related [relevance 5%]
* [PATCH] Makefile: use VCSSVN_LIB to refer to svn library
2016-07-01 7:56 5% [PATCH] Makefile: drop extra dependencies for test helpers Jeff King
@ 2016-07-01 7:59 5% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2016-07-01 7:59 UTC (permalink / raw)
To: git
We have an abstracted variable; let's use it consistently.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of the cleanup earlier in the thread.
I actually wonder if we should drop the vcs-svn code entirely. The last
update that wasn't just part of a "I'm grepping the whole code base to
change this interface" patch was almost 4 years ago, and AFAICT it never
reached a shippable point (we _do_ actually install git-remote-testsvn,
but given the name, I sort of assume nobody is using it).
But I don't want to step on the toes of anybody who actually is using
it, or is planning to work on it more.
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 22815a2..4579eab 100644
--- a/Makefile
+++ b/Makefile
@@ -2225,9 +2225,9 @@ perf: all
.PHONY: test perf
-t/helper/test-line-buffer$X: vcs-svn/lib.a
+t/helper/test-line-buffer$X: $(VCSSVN_LIB)
-t/helper/test-svn-fe$X: vcs-svn/lib.a
+t/helper/test-svn-fe$X: $(VCSSVN_LIB)
.PRECIOUS: $(TEST_OBJS)
--
2.9.0.317.g65b4e7c
^ permalink raw reply related [relevance 5%]
* Re: [PATCH v3 2/2] interpret-trailers: add option for in-place editing
@ 2016-01-13 18:15 5% ` Eric Sunshine
0 siblings, 0 replies; 200+ results
From: Eric Sunshine @ 2016-01-13 18:15 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Junio C Hamano, Christian Couder, Matthieu Moy, Git List
On Wed, Jan 13, 2016 at 7:43 AM, Tobias Klauser <tklauser@distanz.ch> wrote:
> Add a command line option --in-place to support in-place editing akin to
> sed -i. This allows to write commands like the following:
>
> git interpret-trailers --trailer "X: Y" a.txt > b.txt && mv b.txt a.txt
>
> in a more concise way:
>
> git interpret-trailers --trailer "X: Y" --in-place a.txt
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
> @@ -326,6 +326,38 @@ test_expect_success 'with complex patch, args and --trim-empty' '
> +test_expect_success 'in-place editing on stdin' '
Maybe say:
"in-place editing on stdin disallowed"
or something?
> + test_must_fail git interpret-trailers --trailer "Reviewed-by: Alice" --in-place < basic_message
> +'
> +
> +test_expect_success 'in-place editing on non-existing file' '
> + test_must_fail git interpret-trailers --trailer "Reviewed-by: Alice" --in-place nonexisting &&
> + test_path_is_missing nonexisting
> +'
An significant shortcoming of the first version of this patch series
was that it did not treat the input file as precious, and would
happily delete it if trailer processing failed for any reason. This is
behavior we'd like to protect against. Toward that end, have you
considered adding a test to verify that the input file is indeed
considered precious, and not deleted upon failure? One way to do so
would be to write a test which triggers one of the failure conditions
of the interpret-trailers framework. Looking at the source code, one
possible way would be to make trailer.c:read_input_file() fail, for
instance, by making the file unreadable (with 'chmod -r', though you'd
have to protect the test with the POSIXPERM prerequisite).
More below.
> diff --git a/trailer.c b/trailer.c
> @@ -858,6 +861,31 @@ void process_trailers(const char *file, int trim_empty, struct string_list *trai
>
> lines = read_input_file(file);
>
> + if (in_place) {
> + struct stat st;
> + struct strbuf template = STRBUF_INIT;
> + const char *tail;
> +
> + if (stat(file, &st))
> + die_errno(_("could not stat %s"), file);
> + if (!S_ISREG(st.st_mode))
> + die(_("file %s is not a regular file"), file);
> + if (!(st.st_mode & S_IWUSR))
> + die(_("file %s is not writable by user"), file);
> +
> + /* Create temporary file in the same directory as the original */
> + tail = strrchr(file, '/');
> + if (tail != NULL)
> + strbuf_add(&template, file, tail - file + 1);
> + strbuf_addstr(&template, "git-interpret-trailers-XXXXXX");
> +
> + xmks_tempfile_m(&trailers_tempfile, template.buf, st.st_mode);
> + strbuf_release(&template);
> + outfile = fdopen_tempfile(&trailers_tempfile, "w");
> + if (!outfile)
> + die_errno(_("could not open temporary file"));
> + }
Hmm, the current logic of process_trailers() is pretty easily
understood at a glance, but this new (relatively huge) chunk of code
obscures the overall operation. Have you considered factoring the new
code out into its own function in order to keep the overall flow of
process_trailers() clean? (Genuine question; I don't necessarily feel
so strongly about it to demand such a change.)
> /* Print the lines before the trailers */
> trailer_end = process_input_file(outfile, lines, &in_tok_first, &in_tok_last);
>
> @@ -872,5 +900,10 @@ void process_trailers(const char *file, int trim_empty, struct string_list *trai
> /* Print the lines after the trailers as is */
> print_lines(outfile, lines, trailer_end, INT_MAX);
>
> + if (in_place) {
> + if (rename_tempfile(&trailers_tempfile, file))
> + die_errno(_("could not rename temporary file to %s"), file);
> + }
You could drop the unnecessary braces.
> strbuf_list_free(lines);
> }
^ permalink raw reply [relevance 5%]
* Re: Bug with .gitignore and branch switching
@ 2017-03-17 21:54 5% ` Jonathan Nieder
1 sibling, 0 replies; 200+ results
From: Jonathan Nieder @ 2017-03-17 21:54 UTC (permalink / raw)
To: Nevada Sanchez; +Cc: git
Hi Nevada,
Nevada Sanchez wrote:
> # Commit a file that will end up in .gitignore
> echo 'original settings' > mine.conf
> git add mine.conf
> git commit -m "Unknowingly committed my settings."
>
> echo '*.conf' > .gitignore
> git add .gitignore
> git commit -m "Users shouldn't commit their settings"
Naming a file in .gitignore tells git that you do not want to track it
and are giving git permission to write over it. This commonly happens
when people check in build products. For example:
git rm -f my-build-product
echo /my-build-product >>.gitignore
git commit -m "Remove generated my-build-product file"
make my-build-product
git checkout HEAD^
Without that rule, this 'git checkout' command would fail.
That said, there are some cases (e.g. the .conf file case you mention)
where a person would want git not to track a file but do not want to
give git permission to write over it. As you've seen, .gitignore does
not work well for this. :/
Ideas for next steps:
1. The gitignore(5) manpage does not do a good job of emphasizing
that files named there are not precious and can be overwritten by
git. Do you have ideas for wording that would help with that?
This would be especially welcome if you can phrase them in the
form of a patch against Documentation/gitignore.txt.
2. Occasionally people have mentioned the idea of a .gitprecious file
listing precious files that git should not track and not overwrite
(e.g., keys and other configuration files, IDE state, or metadata
for another version control system being used in parallel). Would
you be interested in working on that?
Thanks and hope that helps,
Jonathan
^ permalink raw reply [relevance 5%]
* Re: mergetool: what to do about deleting precious files?
@ 2017-05-28 1:14 5% ` Junio C Hamano
2017-05-28 10:24 5% ` Philip Oakley
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2017-05-28 1:14 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
"Philip Oakley" <philipoakley@iee.org> writes:
> The git book [1] and a few blog posts [2] show how to preserve files which
> are in the current branch against changes that are on the branch being
> merged in.
>
> e.g. (from [2])
>
> echo '<filemane> merge=ours' >> .gitattributes && # commit
> git config --global merge.ours.driver true
>
> (test) $ git checkout demo
> (demo) $ git merge -
> # <filename> contents are not merged and the original retained.
>
>
>
> However what is not covered (at least in the documentation ) is the case
> where the file to be ignored is not present on the current branch, but is
> present on the branch to be merged in.
Hmph. Per-path 'ours' and 'theirs' kick in only after we decide to
perform the content level three-way merge. I wonder what would (not
"should", but "would with the current code") happen, with the same
attribute setting, if the file being merged were not changed by ours
but modified by the side branch? I suspect that we'd take the change
made by the side branch.
> Normal expectations would be that in such a case the new file from the
> second parent branch would be added to the current branch.
So I do not think this is not limited to "new file". Anything that
a tree-level three-way merge would resolve cleanly without having to
consult the content-level three-way merge will complete without
consulting the merge.ours.driver; per-file content-level three-way
merge driver (which is what merge=<drivername> mechanism lets you
specify via the attributes mechanism) is not something you would
want to use for this kind of thing. It is purely for resolving the
actual content-level conflicts.
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
2018-11-28 21:54 5% ` Ævar Arnfjörð Bjarmason
@ 2018-12-01 6:21 5% ` Duy Nguyen
0 siblings, 0 replies; 200+ results
From: Duy Nguyen @ 2018-12-01 6:21 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, per.lundberg, brian m. carlson, Git Mailing List,
jost, Joshua Jensen, git, Clemens Buchacher,
Holger Hellmuth (IKS), Kevin Ballard
On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> But we must have some viable way to repair warts in the tools, and
> losing user data is a *big* wart.
>
> I don't think something like the endgame you've described in
> https://public-inbox.org/git/xmqqzhtwuhpc.fsf@gitster-ct.c.googlers.com/
> is ever going to work. Novice git users (the vast majority) are not
> going to diligently update both .gitignore and some .gitattribute
> mechanism in lockstep. I'd bet most git users haven't read more than a
> few paragraphs of our entire documentation at best.
>
> So what's the way forward? I think ultimately we must move to something
> where we effectively version the entire CLI UI similar to stable API
> versions. I.e. for things like this that would break some things (or
> Duy's new "split checkout") introduce them as flags first, then bundle
> up all such flags and cut a major release "Git 3, 4, ...", and
> eventually remove old functionality.
Related to Duy's new "split chekckout", I just realized that I added
--overwrite-ignore (enabled by default) [1] years ago to allow to out
out of this behavior. We could turn --no-overwrite-ignore by default
on the new command "git switch-branch" to err on the safe side. Then
the user could switch to --overwrite-ignore once they learn more about
gitignore and gitattributes (or the coming "backup log"). I'm not sure
if I really like this, but at least it's one of the options.
[1] https://public-inbox.org/git/1322388933-6284-2-git-send-email-pclouds@gmail.com/
--
Duy
^ permalink raw reply [relevance 5%]
* Re: Aborting 'rebase main feat' removes unversioned files
@ 2021-09-04 18:32 5% ` Fedor Biryukov
0 siblings, 0 replies; 200+ results
From: Fedor Biryukov @ 2021-09-04 18:32 UTC (permalink / raw)
To: Jeff King; +Cc: Bagas Sanjaya, git
Actually it's the same on all operating systems. I just forgot to add
a new base commit in main in the reproduction scenario - there was
nothing to rebase...
Here is the correct scenario along with the output.
+ git init -b main repo
Initialized empty Git repository in
/Users/ted/workspace/git-abort-bug/repo/.git/
+ cd repo
+ git commit -m base --allow-empty
[main (root-commit) 3299694] base
+ git checkout -b feat
Switched to a new branch 'feat'
+ echo feat >readme.txt
+ git add readme.txt
+ git commit -m txt=feat
[feat c9dc9b4] txt=feat
1 file changed, 1 insertion(+)
create mode 100644 readme.txt
+ git checkout main
Switched to branch 'main'
+ git commit -m new-base --allow-empty
[main c5c292c] new-base
+ echo precious > readme.txt
+ git rebase main feat
error: The following untracked working tree files would be overwritten by merge:
readme.txt
Please move or remove them before you merge.
Aborting
hint: Could not execute the todo command
hint:
hint: pick c9dc9b4d5aca461f1a1bedd3b99b5c8533d5ef10 txt=feat
hint:
hint: It has been rescheduled; To edit the command before continuing, please
hint: edit the todo list first:
hint:
hint: git rebase --edit-todo
hint: git rebase --continue
Could not apply c9dc9b4... txt=feat
+ cat readme.txt
precious
+ git rebase --abort
+ cat readme.txt
feat
-Fedor
On Sat, Sep 4, 2021 at 12:24 PM Jeff King <peff@peff.net> wrote:
>
> On Sat, Sep 04, 2021 at 12:03:49PM +0200, Fedor Biryukov wrote:
>
> > Here's the output from Windows, where everything works as expected.
> > [...]
> > PS> git rebase main feat
> > error: The following untracked working tree files would be overwritten
> > by checkout:
> > readme.txt
> > Please move or remove them before you switch branches.
> > Aborting
> > error: could not detach HEAD
>
> Interesting that it behaves differently than the mac and linux versions.
> There are some changes between Git for Windows and regular upstream Git,
> but looking over the diff between the v2.33.0 releases, I don't see
> anything that might cause this discrepancy.
>
> If the problem used to occur on v2.31 and now doesn't, it might be
> interesting to bisect it.
>
> -Peff
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
@ 2018-11-12 23:22 5% ` brian m. carlson
2018-11-26 9:30 5% ` Per Lundberg
1 sibling, 1 reply; 200+ results
From: brian m. carlson @ 2018-11-12 23:22 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Nguyễn Thái Ngọc Duy, git, Steffen Jost,
Joshua Jensen, Per Lundberg, Junio C Hamano, Matthieu Moy,
Clemens Buchacher, Holger Hellmuth, Kevin Ballard
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
On Sun, Nov 11, 2018 at 01:33:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
> The users who need protection against git deleting their files the most
> are exactly the sort of users who aren't expert-level enough to
> understand the nuances of how the semantics of .gitignore and "precious"
> are going to interact before git eats their data.
>
> This is pretty apparent from the bug reports we're getting about
> this. None of them are:
>
> "Hey, I 100% understood .gitignore semantics including this one part
> of the docs where you say you'll do this, but just forgot one day
> and deleted my work. Can we get some more safety?"
>
> But rather (with some hyperbole for effect):
>
> "ZOMG git deleted my file! Is this a bug??"
>
> So I think we should have the inverse of this "precious"
> attribute". Just a change to the docs to say that .gitignore doesn't
> imply these eager deletion semantics on tree unpacking anymore, and if
> users want it back they can define a "garbage" attribute
> (s/precious/garbage/).
>
> That will lose no data, and in the very rare cases where a checkout of
> tracked files would overwrite an ignored pattern, we can just error out
> (as we do with the "Ok to overwrite" branch removed) and tell the user
> to delete the files to proceed.
This is going to totally hose automation. My last job had files which
might move from tracked to untracked (a file that had become generated),
and long-running CI and build systems would need to be able to check out
one status and switch to the other. Your proposed change will prevent
those systems from working, whereas they previously did.
I agree that your proposal would have been a better design originally,
but breaking the way automated systems currently work is probably going
to be a dealbreaker.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply [relevance 5%]
* Re: 'git rebase' silently drops changes?
@ 2015-02-09 12:53 5% ` Sergey Organov
0 siblings, 0 replies; 200+ results
From: Sergey Organov @ 2015-02-09 12:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sebastian Schuberth, git
Johannes Sixt <j6t@kdbg.org> writes:
> Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth:
>> On 06.02.2015 22:28, Sergey Organov wrote:
>>
>>> # Now rebase my work.
>>> git rebase -f HEAD~1
>>>
>>> # What? Where is my "Precious" change in "a"???
>>> cat a
>>> </SCRIPT>
>>>
>>> I.e., the modification marked [!] was silently lost during rebase!
>>
>> Just a wild guess: Maybe because you omitted "-p" / "--preserve-merges"
>> from "git rebase"?
>
> No, that would not help. --preserve-merges repeats the merge, but does
> not apply the amendment.
Really? Why? Here the valid concern you gave below doesn't even apply!
Check... yes, git silently drops amend even with --preserve-merges
(script to reproduce at the end[1])! How comes?
> It's just how rebase works: It omits merge commits when it linearizes
> history.
>
> Sergey, it is impossible for git rebase to decide to which rebased
> commit the amendement applies. It doesn't even try to guess. It's the
> responsibility of the user to apply the amendment to the correct
> commit.
Yeah, this sounds reasonable, /except/ git even gives no warning when it
drops amendments. Shouldn't 'git rebase' rather consider merge amendment
a kind of conflict?
[1] To reproduce amend drop by "git rebase --preserve-merges":
<SCRIPT>
git init t
cd t
git config rerere.enabled false # doesn't actually matter either way.
echo "I" > a; git add a
echo "I" > b; git add b
git commit -aqm "I"
git tag start
git checkout -b test
echo "B" >> b; git commit -m "B" -a
git checkout master
echo "A" >> a
git commit -aqm "A"
git merge --no-edit test
git branch -d test
# Clean merge, but result didn't compile, so I fixed it and
# amended the merge:
echo "Precious!" >> a # [!] This is modification that gets lost
git commit --amend --no-edit -aq
cat a
# Make a change earlier in history, to rebase my work on top of it.
git co -q start
git co -b test
echo "C" > c; git add c
git commit -aqm "C"
# Now rebase my work.
git co master
git rebase --preserve-merges --no-fork-point test
# What? Where is my "Precious" change in "a"???
cat a
</SCRIPT>
-- Sergey.
^ permalink raw reply [relevance 5%]
* Re: [PATCH 1/1] Introduce "precious" file concept
@ 2019-02-17 9:31 5% ` Duy Nguyen
2019-02-18 9:53 5% ` Ævar Arnfjörð Bjarmason
0 siblings, 2 replies; 200+ results
From: Duy Nguyen @ 2019-02-17 9:31 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Git Mailing List, Junio C Hamano, Per Lundberg, Steffen Jost,
Joshua Jensen, Matthieu Moy, Clemens Buchacher, Holger Hellmuth,
Kevin Ballard
On Sun, Feb 17, 2019 at 2:36 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Sat, Feb 16 2019, Nguyễn Thái Ngọc Duy wrote:
>
> [Re-CC some people involved the last time around]
>
> > A new attribute "precious" is added to indicate that certain files
> > have valuable content and should not be easily discarded even if they
> > are ignored or untracked.
> >
> > So far there are one part of Git that are made aware of precious
> > files: "git clean" will leave precious files alone.
>
> Thanks for bringing this up again. There were also some patches recently
> to save away clobbered files, do you/anyone else have any end goal in
> mind here that combines this & that, or some other thing I may not have
> kept up with?
I assume you mean the clobbering untracked files by merge/checkout.
Those files will be backed up [1] if backup-log is implemented. Even
files deleted by "git clean" could be saved but that might go a little
too far.
[1] https://public-inbox.org/git/20181209104419.12639-20-pclouds@gmail.com/
> My commentary on this whole thing is basically a repeat of what I said
> in https://public-inbox.org/git/87wop0yvxv.fsf@evledraar.gmail.com/
>
> I.e. we have a definite problem here somewhere, and there is some
> solution, but this patch feels a bit like navigating that maze in the
> dark without a map.
>
> We had users report that the likes of "pull" were eating their data, but
> now with this iteration of "precious" only impacting "clean" the only
> problem anyone with the current semantics is still left unaddressed. My
> memory (I may be wrong) is that "clean" was just brought up (by you?) as
> a "what about this other related case?" in that whole discussion.
>
> So as noted in the E-Mail linked above I think the first step should be
> to enumerate/document/test the cases where we're now eating data
> implicitly, and discuss how that relates to the semantics we desired
> when the data-eating behavior was first introduced (as noted in E-Mails
> linked from the above, my own preliminary digging seems to reveal there
> isn't much of a relationship between the two).
>
> Only when we have that list of XYZ cases we're supporting now, and can
> see that XYZ is so important to maintain backwards compatibility for
> that we can't change it should way say "we eat your data by default
> because XYZ is so useful/backcompat, set 'precious' ...".
>
> But right now we don't even have the list of XYZ or tests for them (as
> my RFC "garbage" attribute patch revealed). So this whole thing still
> feels like jumping three steps ahead to me in terms of addressing *that*
> issue, but perhaps you have some orthogonal use-case in mind for this?
I'm not addressing the accidentally losing data in this patch. My
answer for that would still be backup-log, if it ever gets merged. But
this patch is about _known_ files that I want to keep when doing "git
clean", no more.
--
Duy
^ permalink raw reply [relevance 5%]
* Re: clean bug on ignored subdirectories with no tracked files?
@ 2011-11-21 19:28 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2011-11-21 19:28 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Just because it is uninteresting to git does not mean that it isn't
>> precious.
>
> That statement is false with the versions of Git so far. See the other
> thread for the current status and possible future directions.
Oops, sorry, I was really confused. You are right that "ignored" for
"clean" does not mean "they are not tracked and should be removed". That
would result in removal of build artifacts '*.o' and unnecesary
recompilation.
What "precious" means is a bit different, however. With verisons of Git so
far, what "ignored" means is that they are not tracked, and _can_ be
removed when needed to complete normal Git operations. When checking out
another branch that has a tracked file at the same path as an untracked
and ignored file in your current branch, removal of that ignored file is
necessary to complete the checkout, and for that purpose, the ignored file
is considered expendable. And we do not have a concept of "precious",
unexpendable but untracked file, nor a way to specify that to gitignore
mechanism (which is the topic of the other discussion thread).
"clean" without "-x" is meant to preserve untracked but expendable paths
(e.g. build products), so if something is removed that is untracked but
matches the ignore pattern, then that is a bug to be fixed. Care to roll
a patch to fix it?
Sorry for the confusion, but as I said, I do not use (hence nor care much
about) "clean" myself, so...
^ permalink raw reply [relevance 5%]
* Re: mergetool: what to do about deleting precious files?
2017-05-28 10:24 5% ` Philip Oakley
@ 2017-05-28 13:06 5% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2017-05-28 13:06 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
"Philip Oakley" <philipoakley@iee.org> writes:
>> So I do not think this is not limited to "new file". Anything that
>> a tree-level three-way merge would resolve cleanly without having to
>> consult the content-level three-way merge will complete without
>> consulting the merge.ours.driver; per-file content-level three-way
>> merge driver (which is what merge=<drivername> mechanism lets you
>> specify via the attributes mechanism) is not something you would
>> want to use for this kind of thing. It is purely for resolving the
>> actual content-level conflicts.
>>
> That (that Git knows best) sounds just wrong.
Don't twist my words. I never said Git knows best.
The user-level merge driver is a mechanism to affect conflict level
three-way merges. The interface to the content level three-way
merge driver feeds three versions of blobs and the driver is
expected to give a merged result. The interface as designed is
incapable of passing "here is the common ancestor", "our side is
missing" and "their side is this content".
So if we want a mechanism that can affect the outcome of tree-level
three-way merge, we need a _new_ mechanism. The existing merge
drivers that are written by end users (at least the ones written
correctly to the spec, anyway) are not expecting to be called with
"in our tree, there is no blob here", and trying to piggyback on it
will break existing users.
^ permalink raw reply [relevance 5%]
* [PATCH 1/2] t4151: document a pair of am --abort bugs
@ 2021-09-08 2:17 5% ` Elijah Newren via GitGitGadget
1 sibling, 0 replies; 200+ results
From: Elijah Newren via GitGitGadget @ 2021-09-08 2:17 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, Elijah Newren
From: Elijah Newren <newren@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t/t4151-am-abort.sh | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 9d8d3c72e7e..501a7a9d211 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -23,7 +23,11 @@ test_expect_success setup '
test_tick &&
git commit -a -m $i || return 1
done &&
+ git branch changes &&
git format-patch --no-numbered initial &&
+ git checkout -b conflicting initial &&
+ echo different >>file-1 &&
+ git commit -a -m different &&
git checkout -b side initial &&
echo local change >file-2-expect
'
@@ -191,4 +195,31 @@ test_expect_success 'am --abort leaves index stat info alone' '
git diff-files --exit-code --quiet
'
+test_expect_failure 'git am --abort return failed exit status when it fails' '
+ test_when_finished "rm -rf file-2/ && git reset --hard" &&
+ git checkout changes &&
+ git format-patch -1 --stdout conflicting >changes.mbox &&
+ test_must_fail git am --3way changes.mbox &&
+
+ git rm file-2 &&
+ mkdir file-2 &&
+ echo precious >file-2/somefile &&
+ test_must_fail git am --abort &&
+ test_path_is_dir file-2/
+'
+
+test_expect_failure 'git am --abort returns us to a clean state' '
+ git checkout changes &&
+ git format-patch -1 --stdout conflicting >changes.mbox &&
+ test_must_fail git am --3way changes.mbox &&
+
+ # Make a change related to the rest of the am work
+ echo related change >>file-2 &&
+
+ # Abort, and expect the related change to go away too
+ git am --abort &&
+ git status --porcelain -uno >actual &&
+ test_must_be_empty actual
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related [relevance 5%]
* Re: mergetool: what to do about deleting precious files?
2017-05-30 23:04 5% ` Philip Oakley
@ 2017-05-31 0:02 5% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-05-31 0:02 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Junio C Hamano" <gitster@pobox.com>
>
> Thanks for the replies. Let's see if I've got it...
>
>> "Philip Oakley" <philipoakley@iee.org> writes:
>>
>>> If I now understand correctly, the merge process flow is:
>>>
>>> * canonicalise content (eol, smudge-clean, $id, renormalise, etc)
>>> * diff the content (internal, or GIT_EXTERNAL_DIFF)
>>> * apply the diff
>>> * if conflicts, only then use merge-driver/tool
>>>
>>> Would that be a correct interpretation?
>>
>> Not quite. There are a lot more going on before any of those steps:
>>
>> * Find the common ancestor commit (which could be many).
>
> IIUC Git selects one of them, rather than all if there are many (which
> then may not be the optimum)
Not quite. The interface to "git merge-$backend" can take more than
one and "git merge" frontend does pass them to the backend. How
they are used depends on the backend. The "resolve" one tries to
use all of them at once; the "recursive" one tries merge across them
to come up with a tree to be used as a single "virtual common
ancestor". But details does not matter for the purpose of analysing
the case that triggered this discussion.
>>
>> * Walk the three trees (the common ancestor's, ours and theirs) in
>> parallel, noticing what happened to each path. Depending on what
>> happened to the path in each branch, the merge may or may not
>> "conflict" (e.g. when both sides added exactly the same contents
>> to the same path, they are not counted as conflicting. when we
>> removed while they modified, they show as conflicting).
>
> I'm assuming here that this is the sha-oid comparison, and then
> checking the tree/blob names that match them. (the top tree not having
> a name). So here "conflict free" is that the sha-oids match.
>
> Also, I thnk this is saying that added or removed trees or blobs are
> in some sense are 'conflict free' (though still subject to rename/move
> detection etc). An added file/blob would be conflict free for merging
> into it's tree, yes?
After "recursive" figures out the renames, an addition that still
remains (i.e. not matched up with a deletion elsewhere) would be a
candidate to be added silently (except that D/F conflict can still
be diagnosed).
>> * For paths that are conflicting, feed the canonicalized content of
>> the versions from common, ours and theirs to the file-level merge
>> driver.
>
> So this is where any .gitattibutes settings come in, or is the merge
> driver after the diff step? (which could also be a user diff?)
I think you answered this yourself in your "Ok, I think I can see
how I was confused..." paragraph.
^ permalink raw reply [relevance 5%]
* [BUG] Silent data loss on merge with uncommited changes + renames
@ 2013-04-22 9:24 5% Matthieu Moy
0 siblings, 0 replies; 200+ results
From: Matthieu Moy @ 2013-04-22 9:24 UTC (permalink / raw)
To: git
Hi,
Following the discussion on "merge with uncommited changes" inside the
"git pull --autostash" thread, I did a bit of testing, and encountered a
case with silent data loss. In short: merge a branch introducing changes
to a file. If the file has been renamed in the current branch, then "git
merge" follows the rename and brings changes to the renamed file, but
uncommited changes in this file are overriden silently.
I could have expected "git merge --abort" to fail, but the problem is
really more serious here: data loss is done silently before giving me an
opportunity to do or abort anything.
Reproduction script below:
#! /bin/sh
# Create repo
git init git.$$
cd git.$$
echo init > test.txt
git add test.txt
git commit -m init
# Make a branch changing test.txt
git checkout -b branch
echo new > test.txt
git commit -am new
# Move test.txt on master
git checkout master
git mv test.txt moved.txt
git commit -m move
# Make uncommited changes to moved.txt
echo precious > moved.txt
# Merge loses uncommited content "precious" in "moved.txt" silently
git merge --no-edit branch
ls # lists just moved.txt
git status # nothing to commit, working directory clean
cat moved.txt # Says "new".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [relevance 5%]
* Re: [RFC PATCH] Introduce "precious" file concept
@ 2018-11-12 12:45 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-11-12 12:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Per Lundberg, Duy Nguyen, Git Mailing List, jost,
Joshua Jensen, Clemens Buchacher, Holger Hellmuth (IKS),
Kevin Ballard
On Mon, Nov 12 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> What I'd add to your list is:
>>
>> * Some projects (I've seen this in the wild) add e.g. *.mp3 or whatever
>> else usually doesn't belong in the repo as a "soft ignore". This is
>> something we've never recommended, but have implicitly supported since
>> the only caveats are a) you need a one-off "git add -f" and then
>> they're tracked b) them being missing from "status" before being
>> tracked c) the issue under discussion here.
>
> Or only selected "*.o" (vendor supplied binary blob) kept tracked
> while everything else is built from the source.
>
> I do not know who you are referring to "we" in your sentence, but as
> far as I am concerned, it has been and still is a BCP recommendation
> on this list to deal with a case like that.
I mean that this use-case of having a "soft" ignore by carrying it
across the "git add" barrier with a one-off "-f" isn't something
explicitly documented, and apparently not something many
expect. I.e. you / Matthieu have mentioned .gitignore in the past for
only-generated *.o use-case.
But it also does get used for "mostly we don't want this file, but
sometimes we do" use-case, so that's something we need to deal with in
practice. Like many workflows in git it's not something that was forseen
or intended, but does happen in the wild.
^ permalink raw reply [relevance 6%]
* [PATCH v3 05/53] builtin/prune: convert to struct object_id
@ 2017-05-06 22:09 6% ` brian m. carlson
0 siblings, 0 replies; 200+ results
From: brian m. carlson @ 2017-05-06 22:09 UTC (permalink / raw)
To: git
Cc: Michael Haggerty, Jonathan Tan, Stefan Beller, Jeff King,
Nguyễn Thái Ngọc Duy, Brandon Williams
Convert the sole instance of unsigned char [20] to struct object_id.
cmd_prune is a caller of parse_object, which we will convert later.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
builtin/prune.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index 42633e0c6..96dca7d58 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -123,11 +123,11 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
die(_("cannot prune in a precious-objects repo"));
while (argc--) {
- unsigned char sha1[20];
+ struct object_id oid;
const char *name = *argv++;
- if (!get_sha1(name, sha1)) {
- struct object *object = parse_object_or_die(sha1, name);
+ if (!get_oid(name, &oid)) {
+ struct object *object = parse_object_or_die(oid.hash, name);
add_pending_object(&revs, object, "");
}
else
^ permalink raw reply related [relevance 6%]
* Re: [PATCH v4 4/4] worktree: teach "add" to check out existing branches
@ 2018-03-20 8:02 6% ` Eric Sunshine
0 siblings, 0 replies; 200+ results
From: Eric Sunshine @ 2018-03-20 8:02 UTC (permalink / raw)
To: Thomas Gummerer
Cc: Git List, Nguyễn Thái Ngọc Duy, Junio C Hamano
On Sat, Mar 17, 2018 at 6:22 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> [...]
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else. This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
> [...]
> We will still 'die()' if the branch is checked out in another worktree,
> unless the --force flag is passed.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -61,8 +61,13 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
> If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
> -then, as a convenience, a new branch based at HEAD is created automatically,
> -as if `-b $(basename <path>)` was specified.
> +then, as a convenience, a worktree with a branch named after
> +`$(basename <path>)` (call it `<branch>`) is created. If `<branch>`
> +doesn't exist, a new branch based on HEAD is automatically created as
> +if `-b <branch>` was given. If `<branch>` exists in the repository,
> +it will be checked out in the new worktree, if it's not checked out
> +anywhere else, otherwise the command will refuse to create the
> +worktree.
Should this mention --force?
... refuse to create the worktree (unless --force is used).
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -29,6 +29,7 @@ struct add_opts {
> int keep_locked;
> const char *new_branch;
> int force_new_branch;
> + int checkout_existing_branch;
As 'force_new_branch' and 'checkout_existing_branch' are mutually
exclusive, I wonder if they should be combined into an enum to make it
easier to reason about.
> @@ -318,8 +319,11 @@ static int add_worktree(const char *path, const char *refname,
> - if (opts->new_branch)
> - fprintf(stderr, _("creating new branch '%s'"), opts->new_branch);
> + if (opts->checkout_existing_branch)
> + fprintf(stderr, _("checking out branch '%s'"),
> + refname);
As with "creating branch" in 2/4, "checking out branch..." here is
missing a newline.
> + else if (opts->new_branch)
> + fprintf(stderr, _("creating branch '%s'"), opts->new_branch);
>
> fprintf(stderr, _("worktree HEAD is now at %s"),
> find_unique_abbrev(commit->object.oid.hash, DEFAULT_ABBREV));
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> @@ -198,13 +198,22 @@ test_expect_success '"add" with <branch> omitted' '
> -test_expect_success '"add" auto-vivify does not clobber existing branch' '
> +test_expect_success '"add" auto-vivify checks out existing branch' '
> test_commit c1 &&
> test_commit c2 &&
> git branch precious HEAD~1 &&
> - test_must_fail git worktree add precious &&
> + git worktree add precious &&
> test_cmp_rev HEAD~1 precious &&
> - test_path_is_missing precious
> + (
> + cd precious &&
> + test_cmp_rev precious HEAD
> + )
> +'
This test is no longer checking auto-vivification ("bringing a new
branch to life automatically"), but rather branch name inference, so
the title is now misleading. Perhaps retitle it to '"add" checks out
existing branch of dwim'd name' or something.
(The name "precious" is also now misleading since it's no longer
checking that a precious branch does not get clobbered, however,
changing the name would make the diff unnecessarily noisy, so it's
probably okay as is.)
> +test_expect_success '"add" auto-vivify fails with checked out branch' '
> + git checkout -b test-branch &&
> + test_must_fail git worktree add test-branch &&
> + test_path_is_missing test-branch
> '
Should we also have a corresponding test that this "fail" can be
overridden by --force? (I realize that --force is tested elsewhere,
but only with an explicitly-provided branch name, whereas this dwims
the branch name.)
^ permalink raw reply [relevance 6%]
* [PATCH] cogito: "make clean" fails if make is not GNU make
@ 2006-06-27 16:58 6% Dennis Stosberg
0 siblings, 0 replies; 200+ results
From: Dennis Stosberg @ 2006-06-27 16:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
GNU make automatically passes the -w option when -C is used. On
systems where GNU make is called "gmake", invoking "make" from within
the Makefile will run a make that may not understand that option:
$ gmake -C Documentation/ clean
gmake: Entering directory `/usr/home/dennis/tmp/cogito/Documentation'
make -C tutorial-script clean
make: don't know how to make w. Stop
gmake: *** [clean] Error 2
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
Documentation/Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 36295a7..b48e49c 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -60,10 +60,10 @@ install-html: html
$(INSTALL) $(DOC_HTML) $(DESTDIR)/$(htmldir)
test:
- make -C tutorial-script test
+ $(MAKE) -C tutorial-script test
clean:
- make -C tutorial-script clean
+ $(MAKE) -C tutorial-script clean
rm -f *.xml *.html *.pdf *.1 *.7 cg*.[17].txt $(PACKAGE).7.txt
.PRECIOUS: cg%.txt introduction.txt
--
1.4.1.rc1.ge6b53
^ permalink raw reply related [relevance 6%]
Results 201-400 of ~1300 next [<= 4%] | prev [>= 6%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2006-06-27 16:58 6% [PATCH] cogito: "make clean" fails if make is not GNU make Dennis Stosberg
2013-04-22 9:24 5% [BUG] Silent data loss on merge with uncommited changes + renames Matthieu Moy
2016-07-01 7:56 5% [PATCH] Makefile: drop extra dependencies for test helpers Jeff King
2016-07-01 7:59 5% ` [PATCH] Makefile: use VCSSVN_LIB to refer to svn library Jeff King
2010-06-23 19:48 5% [PATCH 4/4] Makefile: Don't pass $(ALL_CFLAGS) to the linker Ramsay Jones
2015-12-22 17:39 5% [PATCH] l10n: de.po: translate 68 new messages Ralf Thielow
2015-12-29 18:18 5% ` [PATCH v3] " Ralf Thielow
2006-03-22 9:48 5% Warning: fetch updated the current branch head Junio C Hamano
2013-02-07 6:34 5% Hyper links of london sale occurs in several designs deishei001
2009-12-27 6:55 5% [PATCH] Don't pass CFLAGS to the linker Tomas Carnecky
2005-08-06 5:36 5% [PATCH] Making CFLAGS compilant with GNU Coding Standards Pavel Roskin
2010-09-04 20:19 5% [RFC PATCH] Teach checkout the -n|--dry-run option Jens Lehmann
2011-05-06 22:12 5% [PATCH] " Jens Lehmann
2009-04-23 1:46 5% [PATCH] Convert to use quiet option when available Dan Loewenherz
[not found] <CAGF1KhWNaO_TUuCPo2L_HzNnR+FnB1Q4H6_xQ2owoH+SnynzEg@mail.gmail.com>
2024-01-22 20:45 ` Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory Raúl Núñez de Arenas Coronado
2024-01-22 21:34 ` Jeff King
2024-01-23 5:40 5% ` Raúl Núñez de Arenas Coronado
2024-01-24 1:09 ` Jeff King
2024-01-24 14:22 4% ` Raúl Núñez de Arenas Coronado
[not found] <200709301421.52192.bruno@clisp.org>
[not found] ` <200710021350.54625.bruno@clisp.org>
2007-10-02 12:16 ` git: avoiding merges, rebasing Eric Blake
2007-10-03 21:31 ` making "git stash" safer to use Bruno Haible
2007-10-03 21:36 4% ` Junio C Hamano
[not found] <CAG2t84Uaw-Kdp+EXU8CY1QYfykFQj-hGLJnTSH8MYO8Vi_yqgA@mail.gmail.com>
2021-09-03 20:33 ` Aborting 'rebase main feat' removes unversioned files Fedor Biryukov
2021-09-04 6:57 ` Bagas Sanjaya
2021-09-04 9:48 ` Jeff King
2021-09-04 9:51 ` Fedor Biryukov
2021-09-04 10:18 ` Jeff King
2021-09-05 5:32 ` Elijah Newren
2021-09-05 7:43 4% ` Ævar Arnfjörð Bjarmason
2021-09-08 0:40 5% ` Elijah Newren
2021-09-04 9:58 ` Fedor Biryukov
2021-09-04 10:03 ` Fedor Biryukov
2021-09-04 10:24 ` Jeff King
2021-09-04 18:32 5% ` Fedor Biryukov
2023-06-21 10:21 4% [PATCH] t7701: make annotated tag unreachable Taylor Blau
2008-03-18 18:01 4% auto gc again Jens Axboe
2021-09-30 17:15 4% Should help.autocorrect be on by default? Brian Bartels
[not found] <1009315412.367253372.1418981868176.JavaMail.root@zimbra39-e7.priv.proxad.net>
2014-12-19 9:42 4% ` [BUG] interactive rebase loses instruction sheet when aborting to avoid overwriting files ydirson
2007-07-08 16:23 4% [PATCH 0/4] Add git-rewrite-commits skimo
2013-03-29 16:29 Minor bug in git branch --set-upstream-to adding superfluous branch section to config Phil Haack
2013-03-29 17:00 ` Jeff King
2013-03-29 17:20 4% ` Thomas Rast
2010-11-04 9:43 [PATCH] git-rebase--interactive.sh: Add new command "shell" Kevin Ballard
2010-11-04 10:25 ` Yann Dirson
2010-11-04 17:04 ` Eric Raible
2010-11-04 17:34 ` Matthieu Moy
2010-11-04 18:10 ` Jonathan Nieder
2010-11-04 20:53 ` Yann Dirson
2010-11-08 18:31 4% ` Junio C Hamano
2011-11-20 13:42 Bug report - local (and git ignored) file silently removed after checkout Bertrand BENOIT
2011-11-20 21:16 4% ` Junio C Hamano
2011-11-20 22:19 ` Taylor Hedberg
2011-11-21 3:36 ` Junio C Hamano
2011-11-21 7:23 ` [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude Johannes Sixt
2011-11-21 8:17 ` Nguyen Thai Ngoc Duy
2011-11-21 15:18 ` Junio C Hamano
2011-11-21 15:44 4% ` Bertrand BENOIT
2011-11-27 10:13 4% ` Nguyen Thai Ngoc Duy
2011-11-27 10:15 ` [PATCH 1/2] checkout,merge: loosen overwriting untracked file check based on info/exclude Nguyễn Thái Ngọc Duy
2011-11-29 18:17 4% ` Junio C Hamano
2015-08-13 18:02 [PATCH 1/2] prepare_packed_git(): refactor garbage reporting in pack directory Doug Kelly
2015-08-13 18:46 ` Eric Sunshine
2015-08-17 16:53 ` Junio C Hamano
2015-10-28 17:48 ` Junio C Hamano
2015-10-28 22:43 ` Doug Kelly
2015-11-04 3:12 ` Doug Kelly
2015-11-04 19:35 ` Junio C Hamano
2015-11-04 19:56 ` Doug Kelly
2015-11-04 20:02 ` Jeff King
2015-11-04 20:08 ` Doug Kelly
2015-11-04 20:15 4% ` Jeff King
2018-12-01 22:51 [RFC] git clean --local Cameron Boehmer
2018-12-02 0:04 4% ` Junio C Hamano
2018-12-02 13:25 ` Ævar Arnfjörð Bjarmason
2018-12-02 17:37 4% ` Randall S. Becker
2018-12-02 19:37 4% ` Junio C Hamano
2007-10-05 0:15 [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit Steven Grimm
2007-10-05 8:21 4% ` Peter Baumann
2018-03-17 22:08 [PATCH v3 0/4] worktree: teach "add" to check out existing branches Thomas Gummerer
2018-03-17 22:22 ` [PATCH v4 " Thomas Gummerer
2018-03-17 22:22 ` [PATCH v4 4/4] " Thomas Gummerer
2018-03-20 8:02 6% ` Eric Sunshine
2021-05-05 19:51 [feature suggestion] Add 'git stash export', 'git stash import' commands to allow to backup stash externally Yuri
2021-05-06 6:07 4% ` Johannes Sixt
2021-05-06 6:12 ` Yuri
2021-05-06 6:43 4% ` Johannes Sixt
2016-03-23 10:04 [PATCH 00/21] replacement for dt/refs-backend-lmdb v7 patch 04/33 Michael Haggerty
2016-03-23 10:04 5% ` [PATCH 05/21] t1430: improve test coverage of deletion of badly-named refs Michael Haggerty
2018-12-09 20:04 [PATCH 0/8] introduce no-overlay and cached mode in git checkout Thomas Gummerer
2018-12-09 20:04 ` [PATCH 6/8] checkout: add --cached option Thomas Gummerer
2018-12-10 16:49 ` Duy Nguyen
2018-12-11 3:13 ` Junio C Hamano
2018-12-11 6:12 ` Elijah Newren
2018-12-11 19:23 ` Duy Nguyen
2019-01-31 5:54 ` Duy Nguyen
2019-01-31 19:05 ` Junio C Hamano
2019-02-01 6:48 ` Duy Nguyen
2019-02-01 17:57 ` Junio C Hamano
2019-02-19 4:20 ` Duy Nguyen
2019-02-19 14:42 ` Elijah Newren
2019-02-19 19:07 ` Junio C Hamano
2019-02-19 22:24 4% ` Elijah Newren
2019-11-23 20:50 [PATCH 0/8] Drop support for git rebase --preserve-merges Johannes Schindelin via GitGitGadget
2021-09-01 11:57 ` [PATCH v2 0/7] " Johannes Schindelin via GitGitGadget
2021-09-01 22:25 ` Junio C Hamano
2021-09-02 14:18 4% ` Johannes Schindelin
2007-01-06 10:23 [PATCH] git-reset --hard: use quotes when we tell the user what HEAD was reset to Fredrik Kuivinen
2007-01-06 19:26 4% ` Junio C Hamano
2017-03-17 20:42 Bug with .gitignore and branch switching Nevada Sanchez
2017-03-17 21:54 5% ` Jonathan Nieder
2017-03-17 21:23 ` Junio C Hamano
2017-03-17 22:02 ` Jonathan Nieder
2017-03-17 22:36 4% ` Junio C Hamano
2009-08-27 15:30 Question regarding git fetch Tom Lambda
2009-08-27 15:36 ` Avery Pennarun
2009-08-27 16:46 ` Björn Steinbrink
2009-08-27 17:22 ` Avery Pennarun
2009-08-27 20:48 ` Jeff King
2009-08-27 21:34 ` Jeff King
2009-08-27 21:44 ` Junio C Hamano
2009-08-27 21:50 4% ` Jeff King
2009-09-04 15:54 Commit to wrong branch. How to fix? Howard Miller
2009-09-04 16:19 ` Michael J Gruber
2009-09-04 18:01 4% ` Howard Miller
2010-03-20 9:18 GSoC draft proposal: Line-level history browser Bo Yang
2010-03-20 20:35 ` Alex Riesen
2010-03-23 11:22 ` Jakub Narebski
2010-03-23 12:23 ` Bo Yang
2010-03-23 13:49 ` Jakub Narebski
2010-03-23 15:23 ` Bo Yang
2010-03-23 19:57 ` Jonathan Nieder
2010-03-24 2:30 4% ` Bo Yang
2010-03-20 21:58 ` A Large Angry SCM
2010-03-21 6:16 4% ` Bo Yang
2010-03-22 3:48 ` Bo Yang
2010-03-22 4:24 ` Junio C Hamano
2010-03-22 4:34 ` Bo Yang
2010-03-22 5:32 ` Junio C Hamano
2010-03-22 7:31 ` Bo Yang
2010-03-22 7:41 ` Junio C Hamano
2010-03-22 8:10 ` Jonathan Nieder
2010-03-23 6:01 ` Bo Yang
2010-03-23 18:57 ` Jonathan Nieder
2010-03-24 2:39 4% ` Bo Yang
2019-04-04 10:28 What's cooking in git.git (Apr 2019, #01; Thu, 4) Junio C Hamano
2019-04-04 11:08 4% ` Duy Nguyen
2010-12-05 20:23 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano
2010-12-06 7:29 4% ` Yann Dirson
2015-02-06 21:28 'git rebase' silently drops changes? Sergey Organov
2015-02-07 21:32 ` Sebastian Schuberth
2015-02-08 13:49 ` Johannes Sixt
2015-02-09 12:53 5% ` Sergey Organov
2023-06-14 19:25 [PATCH 0/9] Repack objects into separate packfiles based on a filter Christian Couder
2023-06-14 19:25 ` [PATCH 6/9] repack: add `--filter=<filter-spec>` option Christian Couder
2023-06-16 0:43 5% ` Junio C Hamano
2011-04-08 20:30 git rebase --continue automatic --skip? skillzero
2011-04-09 0:03 ` Jeff King
2011-04-09 13:03 4% ` Peter Baumann
2015-05-18 15:05 [PATCH 00/14] Make git-pull a builtin Paul Tan
2015-05-18 15:06 5% ` [PATCH 08/14] pull: fast-forward working tree if head is updated Paul Tan
2021-08-19 17:16 [PATCH 0/2] test-lib-functions.sh: keep user's HOME, TERM and SHELL for 'test_pause' and 'debug' Philippe Blain via GitGitGadget
2021-08-19 18:10 ` Eric Sunshine
2021-08-19 20:03 ` Elijah Newren
2021-08-19 20:11 4% ` Eric Sunshine
2011-11-19 5:38 clean bug on ignored subdirectories with no tracked files? Jay Soffian
2011-11-19 19:23 ` Junio C Hamano
2011-11-21 18:51 ` Jay Soffian
2011-11-21 19:02 ` Junio C Hamano
2011-11-21 19:28 5% ` Junio C Hamano
2019-08-19 21:41 [PATCH 0/3] git-gui: Add ability to revert selected hunks and lines Pratyush Yadav
2019-08-19 21:41 ` [PATCH 2/3] git-gui: Add the ability to revert selected lines Pratyush Yadav
2019-08-20 19:21 ` Johannes Sixt
2019-08-20 19:29 ` Pratyush Yadav
2019-08-20 21:19 4% ` Johannes Sixt
2018-11-06 15:12 Checkout deleted semi-untracked file Ævar Arnfjörð Bjarmason
2018-11-11 9:52 ` [RFC PATCH] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2018-11-11 12:33 ` Ævar Arnfjörð Bjarmason
2018-11-12 23:22 5% ` brian m. carlson
2018-11-26 9:30 5% ` Per Lundberg
2018-11-26 10:28 5% ` Ævar Arnfjörð Bjarmason
2018-11-26 12:49 ` Junio C Hamano
2018-11-27 15:08 ` Ævar Arnfjörð Bjarmason
2018-11-28 3:58 5% ` Junio C Hamano
2018-11-28 21:54 5% ` Ævar Arnfjörð Bjarmason
2018-12-01 6:21 5% ` Duy Nguyen
2018-11-26 15:26 ` Duy Nguyen
2018-11-26 15:34 ` Ævar Arnfjörð Bjarmason
2018-11-26 15:40 ` Duy Nguyen
2018-11-26 15:47 ` Ævar Arnfjörð Bjarmason
2018-11-26 15:55 ` Duy Nguyen
2018-11-27 9:43 ` Per Lundberg
2018-11-27 12:55 ` Jacob Keller
2018-11-27 14:50 ` Per Lundberg
2018-11-28 1:21 ` brian m. carlson
2018-11-28 6:54 5% ` Per Lundberg
2018-11-11 15:41 ` Duy Nguyen
2018-11-11 16:55 5% ` Ævar Arnfjörð Bjarmason
2018-11-12 7:35 ` Per Lundberg
2018-11-12 9:08 ` Matthieu Moy
2018-11-12 16:07 5% ` Duy Nguyen
2018-11-12 9:49 4% ` Ævar Arnfjörð Bjarmason
2018-11-12 10:26 ` Junio C Hamano
2018-11-12 12:45 6% ` Ævar Arnfjörð Bjarmason
2021-06-29 15:28 PATCH: improve git switch documentation Martin
2021-06-30 8:50 ` Martin
2021-06-30 22:59 ` Junio C Hamano
2021-07-01 10:06 ` Martin
2021-07-01 11:27 ` Sergey Organov
2021-07-07 18:34 ` Felipe Contreras
2021-07-07 20:46 ` Sergey Organov
2021-07-07 21:25 ` What actually is a branch? Felipe Contreras
2021-07-07 22:07 ` Sergey Organov
2021-07-07 22:35 ` Martin
2021-07-08 3:39 ` Felipe Contreras
2021-07-08 10:15 ` Martin
2021-07-08 17:33 ` Felipe Contreras
2021-07-08 19:21 ` Martin
2021-07-08 20:37 ` Felipe Contreras
2021-07-08 23:11 ` Martin
2021-07-09 0:45 ` Felipe Contreras
2021-07-09 14:29 ` PATCH: improve git switch documentation Martin
2021-07-09 16:10 ` Felipe Contreras
2021-07-09 16:51 ` Martin
2021-07-09 17:41 ` Felipe Contreras
2021-07-09 18:23 ` Martin
2021-07-10 19:45 ` Felipe Contreras
2021-07-10 20:07 ` Martin
2021-07-10 20:49 5% ` Felipe Contreras
2015-10-15 19:46 [PATCH v4 00/26] refs backend pre-vtable patches David Turner
2015-10-15 19:46 ` [PATCH v4 26/26] introduce "extensions" form of core.repositoryformatversion David Turner
2015-10-21 19:40 4% ` Junio C Hamano
2015-12-25 19:13 [PATCH] l10n: de.po: translate 68 new messages Phillip Sz
2015-12-25 19:38 5% ` [PATCH v2] " Ralf Thielow
2021-04-07 19:56 No error when overwriting ignored files Horst von Brand
2021-04-07 20:47 4% ` Junio C Hamano
2016-04-27 16:57 [PATCH 00/29] Yet more preparation for reference backends Michael Haggerty
2016-04-27 16:57 5% ` [PATCH 24/29] ref_transaction_update(): check refname_is_safe() at a minimum Michael Haggerty
2006-09-13 15:17 Marking abandoned branches Jon Smirl
2006-09-13 15:24 4% ` Petr Baudis
2012-06-22 7:51 git bisect/checkout and changes to .gitignore Chris Angelico
2012-06-22 10:31 4% ` Johannes Sixt
2012-06-22 17:42 4% ` Junio C Hamano
2010-12-22 11:50 Network problems during "git svn dcommit": need help! Josef Wolf
2010-12-27 0:57 4% ` Network problems during "git svn dcommit" Jonathan Nieder
2010-03-28 19:32 [GSoC Proposal/RFC] Rolling commit message writing Daniel Thomas
2010-03-29 20:31 ` Avery Pennarun
2010-03-30 3:05 ` Jonathan Nieder
2010-03-30 4:32 ` Avery Pennarun
2010-03-30 5:02 4% ` the careless committer and fear of commitment (rebase -i vs add -p) Jonathan Nieder
2010-11-01 22:54 [PATCH 0/2] Work around too many file descriptors Shawn O. Pearce
2010-11-01 22:54 ` [PATCH 1/2] Use git_open_noatime when accessing pack data Shawn O. Pearce
2010-11-03 17:07 ` Junio C Hamano
2010-11-03 17:41 ` Jonathan Nieder
2010-11-03 19:35 ` Junio C Hamano
2010-11-04 5:04 4% ` Jonathan Nieder
2015-07-06 17:30 [PATCH v3 00/23] replace "checkout --to" with "worktree add" Eric Sunshine
2015-07-06 17:30 ` [PATCH v3 22/23] worktree: add: auto-vivify new branch when <branch> is omitted Eric Sunshine
2015-07-06 19:19 ` Junio C Hamano
2015-07-07 1:33 ` Eric Sunshine
2015-07-07 16:10 4% ` Junio C Hamano
2016-01-13 12:43 [PATCH v3 0/2] Add in-place editing support to git interpret-trailers Tobias Klauser
2016-01-13 12:43 ` [PATCH v3 2/2] interpret-trailers: add option for in-place editing Tobias Klauser
2016-01-13 18:15 5% ` Eric Sunshine
2021-12-09 0:57 [PATCH v3 0/4] A design for future-proofing fsync() configuration Neeraj K. Singh via GitGitGadget
2022-02-01 3:33 ` [PATCH v4 " Neeraj K. Singh via GitGitGadget
2022-02-01 3:33 ` [PATCH v4 2/4] core.fsync: introduce granular fsync control Neeraj Singh via GitGitGadget
2022-02-02 0:51 ` Junio C Hamano
2022-02-02 1:42 ` Junio C Hamano
2022-02-11 21:18 5% ` Neeraj Singh
2024-01-09 12:17 [PATCH 0/6] t: mark "files"-backend specific tests Patrick Steinhardt
2024-01-09 12:17 5% ` [PATCH 3/6] t1302: make tests more robust with new extensions Patrick Steinhardt
2024-01-29 11:07 ` [PATCH v4 0/6] t: mark "files"-backend specific tests Patrick Steinhardt
2024-01-29 11:07 4% ` [PATCH v4 3/6] t1302: make tests more robust with new extensions Patrick Steinhardt
2024-01-10 9:01 ` [PATCH v2 0/6] t: mark "files"-backend specific tests Patrick Steinhardt
2024-01-10 9:01 5% ` [PATCH v2 3/6] t1302: make tests more robust with new extensions Patrick Steinhardt
2024-01-24 8:45 ` [PATCH v3 0/6] t: mark "files"-backend specific tests Patrick Steinhardt
2024-01-24 8:45 4% ` [PATCH v3 3/6] t1302: make tests more robust with new extensions Patrick Steinhardt
2021-06-01 6:24 The git spring cleanup challenge Felipe Contreras
2021-06-01 7:28 ` Andy
2021-06-01 10:07 4% ` Felipe Contreras
2015-06-14 8:41 [PATCH v3 00/19] Make git-pull a builtin Paul Tan
2015-06-14 8:41 5% ` [PATCH v3 12/19] pull: fast-forward working tree if head is updated Paul Tan
2016-06-12 21:25 Repacking a repository uses up all available disk space Konstantin Ryabitsev
2016-06-12 21:38 ` Jeff King
2016-06-12 21:54 ` Konstantin Ryabitsev
2016-06-12 22:13 ` Jeff King
2016-06-13 0:24 4% ` Duy Nguyen
2008-10-15 19:24 Usability of git stash Anders Melchiorsen
2008-10-15 19:31 ` Brandon Casey
2008-10-16 11:24 ` David Kastrup
2008-10-16 15:22 ` Brandon Casey
2008-10-18 9:26 ` Anders Melchiorsen
2008-10-20 5:23 4% ` Miles Bader
2009-08-10 9:57 .gitignore vs untracked working file Rostislav Svoboda
2009-08-10 10:01 ` Uwe Kleine-König
2009-08-10 10:17 ` Rostislav Svoboda
2009-08-10 11:41 4% ` Johannes Sixt
2009-09-09 21:27 obnoxious CLI complaints Brendan Miller
2009-09-09 21:54 ` Jakub Narebski
2009-09-10 0:09 ` Brendan Miller
2009-09-10 9:16 ` Jakub Narebski
2009-09-10 18:18 ` Eric Schaefer
2009-09-10 18:52 4% ` Sverre Rabbelier
2023-12-06 11:51 [PATCH 0/7] standardize incompatibility messages René Scharfe
2023-12-06 11:51 5% ` [PATCH 2/7] repack: use die_for_incompatible_opt3() for -A/-k/--cruft René Scharfe
2011-08-12 5:19 [PATCHv2 00/57] Re-roll of en/merge-recursive from pu Elijah Newren
2011-08-12 5:19 5% ` [PATCHv2 01/56] t6042: Add a testcase where git deletes an untracked file Elijah Newren
2006-03-10 14:41 Cogito: Cleanup documentation building and add quick reference Jonas Fonseca
2006-03-10 14:43 5% ` [PATCH 2/4] Encode the manpage section in the file name Jonas Fonseca
2006-03-10 14:44 5% ` [PATCH 3/4] Generate PDF documents using docbook2pdf Jonas Fonseca
2018-10-10 15:09 [PATCH] range-diff: allow to diff files regardless submodule Lucas De Marchi
2018-10-11 0:02 ` brian m. carlson
2018-10-11 7:50 ` Lucas De Marchi
2018-10-12 9:24 4% ` Johannes Schindelin
2009-01-12 22:06 [PATCH/RFC] Documentation/git-mailsplit.txt: Emphasize -o more Junio C Hamano
2009-01-12 22:55 4% ` jidanni
2016-01-22 22:26 Minor bug, git ls-files -o aborts because of broken submodules Jeff King
2016-01-22 22:29 ` [PATCH 2/2] resolve_gitlink_ref: ignore non-repository paths Jeff King
2016-01-22 22:31 4% ` Jeff King
2016-01-22 22:36 4% ` Stefan Beller
2023-03-08 22:39 Fetching everything in another bare repo Paul Smith
2023-03-09 6:41 ` Jeff King
2023-03-09 13:55 ` Paul Smith
2023-03-09 15:35 5% ` Jeff King
2011-02-06 5:13 "git add -u" broken in git 1.7.4? Jeff King
2011-02-06 19:35 ` Sebastian Pipping
2011-02-06 20:48 ` Matthieu Moy
2011-02-07 5:50 ` Junio C Hamano
2011-02-07 5:53 ` Jeff King
2011-02-07 6:46 ` Junio C Hamano
2011-02-07 19:50 ` Jeff King
2011-02-08 10:05 ` SZEDER Gábor
2011-02-09 21:03 ` Jeff King
2011-02-09 22:40 ` Junio C Hamano
2011-02-09 23:46 ` Jeff King
2011-02-10 7:46 4% ` Johannes Sixt
2008-02-02 6:32 [PATCH 1/4] help: make 'git-help--browse' usable outside 'git-help' Christian Couder
2008-02-02 7:30 ` Junio C Hamano
2008-02-03 5:00 4% ` Christian Couder
2023-02-05 16:24 [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true" Tao Klerks via GitGitGadget
2023-02-16 3:22 ` Alex Henrie
2023-02-16 12:31 ` Tao Klerks
2023-02-17 3:15 ` Alex Henrie
2023-02-18 3:17 ` Elijah Newren
2023-02-18 16:39 ` Phillip Wood
2023-02-20 8:03 ` Tao Klerks
2023-02-22 14:27 ` Sergey Organov
2023-02-24 7:06 ` Elijah Newren
2023-02-24 22:06 5% ` Sergey Organov
2017-05-27 10:03 mergetool: what to do about deleting precious files? Philip Oakley
2017-05-28 1:14 5% ` Junio C Hamano
2017-05-28 10:24 5% ` Philip Oakley
2017-05-28 13:06 5% ` Junio C Hamano
2017-05-29 12:57 ` Philip Oakley
2017-05-30 0:52 5% ` Junio C Hamano
2017-05-30 23:04 5% ` Philip Oakley
2017-05-31 0:02 5% ` Junio C Hamano
2007-01-31 19:10 [PATCH] tone down the detached head warning Nicolas Pitre
2007-01-31 23:19 ` Jeff King
2007-02-01 0:11 ` Nicolas Pitre
2007-02-01 3:00 ` Jeff King
2007-02-01 3:23 ` Junio C Hamano
2007-02-01 9:08 ` [PATCH] detached HEAD -- finishing touches Junio C Hamano
2007-02-01 21:52 ` Theodore Tso
2007-02-02 1:11 4% ` Junio C Hamano
2007-02-02 1:16 4% ` Theodore Tso
2019-09-16 14:09 Promoting Ethnics-Ess-Nix, a friends-based search-engine Klaus Sembritzki
2019-09-16 17:16 4% ` Klaus Sembritzki
2021-03-16 0:56 [PATCH 0/7] Sort lists and add static-analysis Denton Liu
2021-03-16 0:56 4% ` [PATCH 1/7] Makefile: mark 'check-builtins' as a .PHONY target Denton Liu
2018-05-24 7:04 [PATCH 0/5] Modernize some testcases for merge-recursive corner cases Elijah Newren
2018-05-24 7:04 5% ` [PATCH 3/5] t6036, t6042: prefer test_path_is_file, test_path_is_missing Elijah Newren
2017-04-15 11:36 Git allow to unconditionaly remove files on other developer host KES
2017-04-15 12:27 4% ` Johannes Sixt
2009-07-15 15:30 "mailinfo: Remove only one set of square brackets" considered harmful Linus Torvalds
2009-07-15 22:09 4% ` Junio C Hamano
2013-10-30 10:58 [PATCH v2] gitk: Add a horizontal scrollbar for commit history Nicolas Cornu
2013-10-30 12:01 4% ` Johannes Sixt
2019-02-16 11:49 [PATCH 0/1] Introduce "precious" file attribute Nguyễn Thái Ngọc Duy
2019-02-16 11:49 ` [PATCH 1/1] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2019-02-16 19:36 ` Ævar Arnfjörð Bjarmason
2019-02-17 9:31 5% ` Duy Nguyen
2019-02-18 9:53 5% ` Ævar Arnfjörð Bjarmason
2019-02-19 18:08 ` Junio C Hamano
2019-02-20 9:19 ` Ævar Arnfjörð Bjarmason
2019-02-20 9:41 5% ` Duy Nguyen
2019-02-20 9:36 5% ` Steffen Jost
2019-02-20 1:35 ` Duy Nguyen
2019-02-20 22:32 5% ` Junio C Hamano
2017-05-06 22:09 [PATCH v3 00/53] object_id part 8 brian m. carlson
2017-05-06 22:09 6% ` [PATCH v3 05/53] builtin/prune: convert to struct object_id brian m. carlson
2016-05-06 16:13 [PATCH v2 00/33] Yet more preparation for reference backends Michael Haggerty
2016-05-06 16:14 5% ` [PATCH v2 28/33] ref_transaction_update(): check refname_is_safe() at a minimum Michael Haggerty
2011-05-25 23:19 [PATCH 0/6] i18n: Windows shellscript support Ævar Arnfjörð Bjarmason
2011-05-25 23:19 5% ` [PATCH 3/6] i18n win32: add git-pull eval_gettext variable prefix Ævar Arnfjörð Bjarmason
2018-10-15 13:01 Ignored files being silently overwritten when switching branches Per Lundberg
2010-08-20 20:35 ` [PATCH] optionally disable overwriting of ignored files Junio C Hamano
2010-08-23 9:37 ` Matthieu Moy
2018-10-16 6:40 ` Ignored files being silently overwritten when switching branches Jeff King
2018-10-16 9:10 ` Ævar Arnfjörð Bjarmason
2018-10-16 15:05 4% ` Duy Nguyen
2018-10-18 1:55 4% ` Junio C Hamano
2011-05-08 11:08 [PATCH] t3703, t4208: add test cases for magic pathspec Nguyễn Thái Ngọc Duy
2011-05-10 5:51 ` [PATCH 0/9] magic pathspec updates Junio C Hamano
2011-05-10 13:47 ` Nguyen Thai Ngoc Duy
2011-05-10 17:07 ` Junio C Hamano
2011-05-11 12:11 4% ` Nguyen Thai Ngoc Duy
2007-10-25 9:25 git-svnimport Felipe Balbi
2007-10-25 10:56 ` git-svnimport Johannes Schindelin
2007-10-25 11:08 ` git-svnimport Felipe Balbi
2007-10-25 13:04 ` git-svnimport Johannes Schindelin
2007-10-25 22:20 4% ` git-svnimport Steven Walter
2019-01-28 2:41 There should be a `.gitbless; file, protecting files from git clean Sebastian Gniazdowski
2019-01-28 5:05 4% ` Duy Nguyen
2019-01-28 5:24 4% ` Sebastian Gniazdowski
2012-07-04 20:43 [RFC PATCH 0/2] Teach rm to better handle submodules Jens Lehmann
2012-07-04 20:44 ` [RFC PATCH 1/2] rm: don't fail when removing populated submodules Jens Lehmann
2012-07-06 6:57 ` Junio C Hamano
2012-07-07 12:51 ` Jens Lehmann
2012-07-08 7:32 ` Junio C Hamano
2012-07-08 15:08 ` Jens Lehmann
2012-07-09 2:17 ` Junio C Hamano
2012-07-09 18:33 ` Jens Lehmann
2012-07-09 19:38 4% ` Junio C Hamano
2011-12-05 20:07 Roadmap for 1.7.9 Junio C Hamano
2011-12-06 11:16 4% ` Nguyen Thai Ngoc Duy
2011-08-24 19:15 git clean --exclude broken? Todd Rinaldo
2011-08-24 21:23 ` Junio C Hamano
2011-08-25 1:38 ` Junio C Hamano
2011-08-25 18:29 ` Re* " Junio C Hamano
2011-08-27 23:54 4% ` Pete Wyckoff
2021-09-08 2:17 [PATCH 0/2] A pair of git am --abort issues Elijah Newren via GitGitGadget
2021-09-08 2:17 5% ` [PATCH 1/2] t4151: document a pair of am --abort bugs Elijah Newren via GitGitGadget
2021-09-10 10:31 ` [PATCH v2 0/3] A pair of git am --abort issues Elijah Newren via GitGitGadget
2021-09-10 10:31 5% ` [PATCH v2 2/3] t4151: add a few am --abort tests Elijah Newren via GitGitGadget
2016-10-11 23:46 [PATCH] convert: mark a file-local symbol static Ramsay Jones
2016-10-15 15:05 ` Lars Schneider
2016-10-15 21:01 ` Ramsay Jones
2016-10-16 0:15 ` Lars Schneider
2016-10-17 1:37 ` Ramsay Jones
2016-10-17 2:18 ` Jeff King
2016-10-17 9:04 ` Johannes Schindelin
2016-10-17 9:37 ` Jeff King
2016-10-17 17:21 ` Ramsay Jones
2016-10-17 20:07 ` Junio C Hamano
2016-10-17 20:48 4% ` Stefan Beller
2023-03-23 16:22 [PATCH 0/8] sequencer refactoring Oswald Buddenhagen
2023-03-23 16:22 ` [PATCH 5/8] rebase: preserve interactive todo file on checkout failure Oswald Buddenhagen
2023-03-23 20:16 ` Junio C Hamano
2023-03-23 23:23 4% ` Oswald Buddenhagen
2018-11-24 2:35 git overwriting local ignored files? David Mandelberg
2018-11-24 4:22 4% ` Junio C Hamano
2008-07-16 18:00 [PATCH,RFC] Implement 'git rm --if-missing' Ciaran McCreesh
2008-07-16 18:06 4% ` Petr Baudis
2019-04-08 4:14 What's cooking in git.git (Apr 2019, #01; Thu, 4) Junio C Hamano
2019-04-09 10:26 ` [PATCH] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2019-04-09 11:31 ` Junio C Hamano
2019-04-10 9:36 ` Duy Nguyen
2019-04-12 1:28 5% ` Junio C Hamano
2015-05-09 17:17 [PATCH v5 0/6] git help: group common commands by theme Sébastien Guimmara
2015-05-09 17:17 ` [PATCH v5 2/6] help.c: output the typical Git workflow Sébastien Guimmara
2015-05-11 6:24 4% ` Eric Sunshine
2015-06-03 6:48 [PATCH v2 00/19] Make git-pull a builtin Paul Tan
2015-06-03 6:48 5% ` [PATCH v2 12/19] pull: fast-forward working tree if head is updated Paul Tan
2019-08-23 20:43 [Feature Request] Option to make .git not read-only in cloned repos Albert Vaca Cintora
2019-08-25 17:54 ` Johannes Sixt
2019-08-25 19:58 ` Albert Vaca Cintora
2019-08-25 22:41 ` Philip Oakley
2019-08-26 14:38 ` Junio C Hamano
2019-08-26 18:42 ` Albert Vaca Cintora
2019-08-26 19:18 4% ` SZEDER Gábor
2007-09-17 15:17 [PATCH] git-merge: add option --no-ff Lars Hjemli
2007-09-17 16:23 ` Lars Hjemli
2007-09-18 0:50 ` Eric Wong
2007-09-18 6:12 ` Lars Hjemli
2007-09-18 6:53 ` Junio C Hamano
2007-09-18 7:30 ` Sam Vilain
2007-09-18 9:12 ` Sam Vilain
2007-09-18 11:19 ` Lars Hjemli
2007-09-18 12:29 ` Johannes Schindelin
2007-09-18 12:38 4% ` Lars Hjemli
2017-07-26 23:29 [RFC PATCH 0/4] Some patches for fsck for missing objects Jonathan Tan
2017-07-26 23:29 ` [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension Jonathan Tan
2017-07-27 18:55 ` Junio C Hamano
2017-07-28 13:20 4% ` Ben Peart
2016-11-01 10:28 Git issue Halde, Faiz
2016-11-01 17:45 ` Jeff King
2016-11-01 18:11 ` Junio C Hamano
2016-11-07 22:34 4% ` Git issue - ignoring changes to tracked file with assume-unchanged Jakub Narębski
2016-06-14 16:07 'untracked working tree files would be overwritten by merge' on ignored files? Andreas Krey
2016-06-14 17:06 4% ` Junio C Hamano
2007-08-18 9:43 Extending .gitignore Dmitry Kakurin
2007-08-18 10:00 4% ` Junio C Hamano
2023-05-11 23:20 [PATCH v3 0/2] pack-objects: introduce `pack.extraRecentObjectsHook` Taylor Blau
2023-06-07 22:58 5% ` [PATCH v5 0/2] gc: introduce `gc.recentObjectsHook` Taylor Blau
2023-05-16 0:23 5% ` [PATCH v4 " Taylor Blau
2023-05-16 0:24 ` [PATCH v4 2/2] " Taylor Blau
2023-05-24 23:21 ` Glen Choo
2023-06-07 22:56 5% ` Taylor Blau
2012-03-27 16:12 Definition of working directory Anjib Mulepati
2012-03-27 17:10 ` Junio C Hamano
2012-03-28 14:10 ` Working directory managment Anjib Mulepati
2012-03-28 15:13 ` Junio C Hamano
2012-03-28 15:39 4% ` Anjib Mulepati
2007-11-12 17:15 Cloning empty repositories, was Re: What is the idea for bare repositories? Johannes Schindelin
2007-11-12 17:24 ` Bill Lear
2007-11-12 17:30 ` Johannes Schindelin
2007-11-12 17:47 ` Matthieu Moy
2007-11-12 17:57 ` Johannes Schindelin
2007-11-12 18:02 ` Matthieu Moy
2007-11-12 18:06 ` Johannes Schindelin
2007-11-12 18:09 ` Matthieu Moy
2007-11-12 21:56 ` Junio C Hamano
2007-11-13 9:48 ` Matthieu Moy
2007-11-13 10:02 ` Shawn O. Pearce
2007-11-13 10:50 ` Matthieu Moy
2007-11-13 19:50 ` Brian Gernhardt
2007-11-13 21:48 ` Matthieu Moy
2007-11-13 23:56 4% ` Johannes Schindelin
2014-05-01 7:43 [PATCH] Add extra logic required to detect endianness on Solaris Charles Bailey
2014-05-01 18:58 5% ` Junio C Hamano
2021-09-18 23:15 [PATCH 0/6] Fix various issues around removal of untracked files/directories Elijah Newren via GitGitGadget
2021-09-24 6:37 4% ` [PATCH v2 " Elijah Newren via GitGitGadget
2021-09-24 6:37 ` [PATCH v2 2/6] Change unpack_trees' 'reset' flag into an enum Elijah Newren via GitGitGadget
2021-09-24 17:35 5% ` Junio C Hamano
2008-10-03 12:27 [FYI][PATCH] Customizing the WinGit installer Petr Baudis
2008-10-06 14:22 ` [msysGit] " Johannes Schindelin
2008-10-06 14:18 ` Petr Baudis
2008-10-06 15:23 ` Johannes Schindelin
2008-10-06 16:00 ` Jakub Narebski
2008-10-06 16:12 ` Johannes Schindelin
2008-10-06 17:34 ` Linus Torvalds
2008-10-06 18:01 ` Johannes Schindelin
2008-10-06 20:11 4% ` [msysGit] " Heikki Orsila
2012-05-31 11:20 [PATCH] i18n: apply: split to fix a partial i18n message Jiang Xin
2012-05-31 13:04 ` Nguyễn Thái Ngọc Duy
2012-05-31 13:04 ` [PATCH 1/6] Remove i18n legos in notifying new branch tracking setup Nguyễn Thái Ngọc Duy
2012-05-31 14:00 4% ` Jonathan Nieder
2024-04-07 5:10 [RFC PATCH 0/1] Add lines to `git log --graph` to separate connected regions Lê Duy Quang
2024-04-07 5:30 ` Eric Sunshine
2024-04-07 5:37 4% ` Junio C Hamano
2024-04-07 6:40 4% ` Quang Lê Duy
2007-07-04 14:36 [PATCH 2/2] filter-branch: fail gracefully when a filter fails Johannes Schindelin
2007-07-05 13:58 ` Jeff King
2007-07-06 3:22 ` Josh Triplett
2007-07-06 3:18 4% ` Johannes Schindelin
2007-07-17 18:28 [PATCH] unpack-trees.c: assume submodules are clean during check-out Sven Verdoolaege
2007-07-18 7:29 ` Junio C Hamano
2007-08-01 14:05 ` Sven Verdoolaege
2007-08-04 5:13 ` Junio C Hamano
2007-08-04 16:03 ` Eran Tromer
2007-08-05 14:46 ` Sven Verdoolaege
2007-08-06 18:42 ` Eran Tromer
2007-08-06 19:03 ` Sven Verdoolaege
2007-08-07 3:24 ` Eran Tromer
2007-08-07 8:51 4% ` Sven Verdoolaege
2011-06-08 7:30 [PATCH 00/48] Handling more corner cases in merge-recursive.c Elijah Newren
2011-06-08 7:30 5% ` [PATCH 01/48] t6039: Add a testcase where git deletes an untracked file Elijah Newren
2017-11-15 15:08 [RFC] Indicate that Git waits for user input via editor Lars Schneider
2017-11-15 17:51 ` Stefan Beller
2017-11-15 18:07 ` Lars Schneider
2017-11-15 18:37 4% ` Stefan Beller
2019-04-11 23:56 [BUG] rebase --interactive silently overwrites ignored files wh
2019-04-12 16:30 4% ` Phillip Wood
2019-04-14 1:59 4% ` wh
2019-05-02 15:45 ` Phillip Wood
2019-05-05 4:02 4% ` Junio C Hamano
2021-06-02 10:31 Request feature: –no-submodule Ilias Apostolou
2021-06-02 20:31 ` Taylor Blau
2021-06-03 0:55 ` Junio C Hamano
2021-06-03 2:33 ` Taylor Blau
2021-06-03 17:40 ` Junio C Hamano
2021-06-03 19:22 ` Jeff King
2021-06-03 21:54 ` Junio C Hamano
2021-06-04 4:03 ` Jeff King
2021-06-04 5:06 ` Junio C Hamano
2021-06-05 5:45 4% ` Ilias Apostolou
2008-07-22 20:01 [FYI PATCH] git wrapper: DWIM mistyped commands Johannes Schindelin
2008-07-22 20:37 4% ` Alex Riesen
2007-08-26 2:59 .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc Dmitry Kakurin
2007-08-26 4:37 ` Junio C Hamano
2007-08-26 5:17 ` Dmitry Kakurin
2007-08-26 5:33 ` Junio C Hamano
2007-08-26 6:36 ` Dmitry Kakurin
2007-08-26 7:28 4% ` Junio C Hamano
2007-08-26 8:02 ` Dmitry Kakurin
2007-08-27 2:51 ` Sam Vilain
2007-08-27 5:52 ` David Kastrup
2007-08-27 10:56 ` Sam Vilain
2007-08-27 11:30 4% ` Johannes Schindelin
2016-07-31 9:21 [RFC/PATCH v11 01/13] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL Pranit Bauva
2016-07-31 9:21 ` [RFC/PATCH v11 13/13] bisect--helper: `bisect_start` shell function partially in C Pranit Bauva
2016-08-02 20:19 5% ` Junio C Hamano
2007-12-07 23:05 Something is broken in repack Jon Smirl
2007-12-11 5:25 ` Jon Smirl
2007-12-11 5:29 ` Jon Smirl
2007-12-11 7:01 ` Jon Smirl
2007-12-11 13:49 ` Nicolas Pitre
2007-12-11 15:00 ` Nicolas Pitre
2007-12-11 16:20 ` Nicolas Pitre
2007-12-11 16:21 ` Jon Smirl
2007-12-12 5:12 ` Nicolas Pitre
2007-12-12 15:48 ` Nicolas Pitre
2007-12-13 13:32 ` Nguyen Thai Ngoc Duy
2007-12-13 15:32 ` Paolo Bonzini
2007-12-13 16:39 4% ` Johannes Sixt
2007-12-14 1:04 ` Jakub Narebski
2007-12-14 6:14 ` Paolo Bonzini
2007-12-14 6:24 4% ` Nguyen Thai Ngoc Duy
2023-10-03 0:30 What's cooking in git.git (Oct 2023, #01; Mon, 2) Junio C Hamano
2023-10-03 7:01 ` Sergey Organov
2023-10-03 16:33 ` Junio C Hamano
2023-10-03 17:59 ` Sergey Organov
2023-10-04 8:20 ` Junio C Hamano
2023-10-04 11:18 ` Sergey Organov
2023-10-05 10:25 ` Junio C Hamano
2023-10-05 20:59 4% ` Sergey Organov
2005-11-30 23:23 [PATCH] Move "-include config.mak" to end of configuration section Timo Hirvonen
2005-12-01 0:46 ` Johannes Schindelin
2005-12-01 1:32 ` [PATCH] Move couple of ifdefs after "include config.mk" Timo Hirvonen
2005-12-01 1:43 ` Junio C Hamano
2005-12-01 8:08 4% ` Johannes Schindelin
2006-05-14 18:36 The git newbie experience Tommi Virtanen
2006-05-14 22:09 ` Junio C Hamano
2006-05-15 5:06 ` Tommi Virtanen
2006-05-15 5:18 ` Junio C Hamano
2006-05-15 5:31 ` Shawn Pearce
2006-05-15 8:39 5% ` Junio C Hamano
2014-10-15 0:45 [PATCH v23 0/25] rs/ref-transaction ("Use ref transactions", part 3) Jonathan Nieder
2014-10-15 0:54 5% ` [PATCH 20/25] refs.c: allow listing and deleting badly named refs Jonathan Nieder
2015-06-18 10:53 [PATCH v4 00/19] Make git-pull a builtin Paul Tan
2015-06-18 10:54 5% ` [PATCH v4 12/19] pull: fast-forward working tree if head is updated Paul Tan
2011-02-15 22:43 non-empty index with git commit -a Sverre Rabbelier
2011-02-16 2:36 ` Jeff King
2011-02-16 3:20 ` Jonathan Nieder
2011-02-16 8:18 4% ` Sverre Rabbelier
2011-02-16 8:51 ` Jeff King
2011-02-16 9:52 ` Sverre Rabbelier
2011-02-16 9:54 ` Jeff King
2011-02-16 10:28 4% ` Matthieu Moy
2011-02-16 9:58 4% ` Sverre Rabbelier
2011-02-16 10:06 4% ` Jeff King
2011-02-16 14:41 4% ` Michael J Gruber
2009-11-10 22:23 git-svn problem with v1.6.5 Pascal Obry
2009-11-11 10:28 ` Pascal Obry
2009-11-11 19:41 ` Avery Pennarun
2009-11-11 19:58 ` Pascal Obry
2009-11-11 20:22 ` Eric Wong
2009-11-11 20:34 ` Eric Wong
2009-11-11 21:55 ` Pascal Obry
2009-11-11 22:44 ` Eric Wong
2009-11-12 6:39 ` Pascal Obry
2009-11-12 7:11 ` Eric Wong
2009-11-12 8:11 4% ` Pascal Obry
2014-11-07 8:13 [RFC] git checkout $tree -- $path always rewrites files Jeff King
2014-11-07 17:14 ` Junio C Hamano
2014-11-07 19:17 ` Jeff King
[not found] ` <CANiSa6hufp=80TaesNpo1CxCbwVq3LPXvYaUSbcmzPE5pj_GGw@mail.gmail.com>
2014-11-08 7:10 ` Martin von Zweigbergk
[not found] ` <CAPc5daWdzrHr8Rdksr3HycMRQu0=Ji7h=BPYjzZj7MH6Ko0VgQ@mail.gmail.com>
2014-11-08 8:30 ` Jeff King
2014-11-08 16:19 ` Martin von Zweigbergk
2014-11-09 9:42 4% ` Jeff King
2011-10-16 7:20 What should "git fetch origin +next" should do? Junio C Hamano
2011-10-17 17:10 ` Jeff King
2011-10-17 18:34 4% ` Junio C Hamano
2021-02-11 0:00 [PATCH] docs: clarify that refs/notes/ do not keep the attached objects alive Martin von Zweigbergk
2021-02-11 0:35 ` Junio C Hamano
2021-02-11 7:14 ` Martin von Zweigbergk
2021-02-11 7:30 4% ` Junio C Hamano
2015-07-17 22:59 [PATCH v3 00/22] rid git-checkout of too-intimate knowledge of new worktree Eric Sunshine
2015-07-17 23:00 5% ` [PATCH v3 13/22] worktree: make --detach mutually exclusive with -b/-B Eric Sunshine
2015-07-17 23:00 5% ` [PATCH v3 14/22] worktree: add: suppress auto-vivication with --detach and no <branch> Eric Sunshine
2009-02-08 20:56 Trouble testing out a patch on a branch new scratch git.git repository Brent Goodrick
2009-02-08 21:46 5% ` Junio C Hamano
2024-01-09 20:20 what should "git clean -n -f [-d] [-x] <pattern>" do? Junio C Hamano
2024-01-19 2:07 ` Elijah Newren
2024-01-23 15:10 ` Sergey Organov
2024-01-23 18:34 ` Junio C Hamano
2024-01-24 8:23 ` Sergey Organov
2024-01-24 17:21 ` Junio C Hamano
2024-01-25 17:11 ` Sergey Organov
2024-01-25 17:46 ` Junio C Hamano
2024-01-25 20:27 ` Sergey Organov
2024-01-25 20:31 ` Sergey Organov
2024-01-26 7:44 ` Junio C Hamano
2024-01-26 12:09 ` Sergey Organov
2024-01-27 10:00 5% ` Junio C Hamano
2022-03-09 23:03 [PATCH v5 0/5] A design for future-proofing fsync() configuration Neeraj K. Singh via GitGitGadget
2022-03-10 9:53 ` [PATCH 7/8] core.fsync: new option to harden loose references Patrick Steinhardt
2022-03-10 22:54 4% ` Neeraj Singh
2006-08-12 0:30 How to resolve git-am conflict (possible bug) Jakub Narebski
2006-08-12 1:20 ` Junio C Hamano
2006-08-12 9:10 4% ` Jakub Narebski
2014-07-30 17:10 Transaction patch series overview Ronnie Sahlberg
2014-07-31 21:41 ` Ronnie Sahlberg
2014-08-08 16:50 ` Ronnie Sahlberg
2014-08-19 19:54 ` Ronnie Sahlberg
2014-08-20 23:17 ` Jonathan Nieder
2014-09-11 3:03 ` [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview) Jonathan Nieder
2014-10-02 1:48 ` [PATCH v22 0/24] rs/ref-transaction Jonathan Nieder
2014-10-02 2:28 5% ` [PATCH 19/24] refs.c: allow listing and deleting badly named refs Jonathan Nieder
2016-01-08 1:28 Should notes handle replace commits? Mike Hommey
2016-01-08 20:09 ` Junio C Hamano
2016-01-08 21:49 ` Mike Hommey
2016-01-08 23:51 ` Junio C Hamano
2016-01-09 0:25 ` Mike Hommey
2016-01-09 1:04 ` Junio C Hamano
2016-01-09 17:39 ` Philip Oakley
2016-01-11 16:50 5% ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).