* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 11:31 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327227956026-7213061.post@n2.nabble.com>
On Sunday, January 22, 2012 at 11:25 CET,
Abscissa <bus_nabble_git@semitwist.com> wrote:
> I saw that, but it seems to imply that it's not a simple:
>
> >git checkout tag_name
>
> because of the required <pathspec>, whatever that is.
It isn't required. The part of the manual that I quoted (from Git
1.7.2.5) indicated that the pathspec is mandatory, but looking at
the command synopsis at the top of the man page it's actually listed
as optional.
Looking at an up to date Git 1.7.9-rc2 man page, it still seems
slightly inconsistent with itself. The synopsis at the top says
git checkout [-p|--patch] [<tree-ish>] [--] [<paths>...]
while the text in the DESCRIPTION section says
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
The DETACHED HEAD section of the man page contains an example of
checking out a tag, by the way.
If you're doubtful, why don't you just create a tag and try things
out for yourself?
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Re: Checkout tag?
From: Jakub Narebski @ 2012-01-22 11:30 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Abscissa, git
In-Reply-To: <20120122101116.GA31022@jpl.local>
Magnus Bäck <magnus.back@sonyericsson.com> writes:
> On Sunday, January 22, 2012 at 11:05 CET,
> Abscissa <bus_nabble_git@semitwist.com> wrote:
>
> > I've managed to figure out you switch branches with the checkout
> > command, like this:
> >
> > $ git checkout branch_name
> >
> > Does that work for tags as well? The docs don't seem clear on that.
> > If not, how do you get the working copy to be a specific tag?
>
> Yes, "git checkout" works for branches, tags, commit SHA-1s, and
> anything else that can be resolved to a SHA-1 identifying what to
> check out. [...]
Note however that because you can generate new commits only on top of
local branches (refs/heads/*), if you check out something other than
local branch, e.g.:
$ git checkout v1.7.8
$ git checkout origin/next
$ git checkout HEAD^
you would be after such checkout in unnamed anonymous branch which
contents corresponds to what you checked out. This state is called
'detached HEAD', and shows e.g. in "git branch output as
$ git branch
* (no branch)
master
...
On the other hand if you don't want to checkout tag to explore it, but
set contents of working area to the state it was in given tag, you can
use
$ git checkout v1.7.8 -- .
HTH
P.S. Instead of Nabble you can use GMane interface, or just use email
(you don't have ot be subscribed to git@vger.kernel.org to post, and
it is custom here to send replies also to author(s)).
--
Jakub Narebski
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:34 UTC (permalink / raw)
To: git
In-Reply-To: <1327228177859-7213081.post@n2.nabble.com>
Sorry for the duplicates. Nabble kept crashing every time I tried to post,
but I guess it was crashing after it posted to the mailing list.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213090.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8AUaJ_tkLSHYPZEPLuiNitRMS77b7n9JFeV6HABHj9Qiw@mail.gmail.com>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213081.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213078.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213076.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213074.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213072.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:27 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213069.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213066.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213063.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: Ramkumar Ramachandra @ 2012-01-22 10:25 UTC (permalink / raw)
To: David Michael Barr; +Cc: git, Junio C Hamano, Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <CAFfmPPOZfDdH+GF91Dxyy5yfX8TmGDmsbpHz=CVLcBY0c-pCsQ@mail.gmail.com>
Hi David,
David Michael Barr wrote:
> Thank you for the feedback, it helped a lot with picking a trajectory.
>
> Video is now available: http://youtu.be/0hVuv-wv4Dw
> Slides: http://barrbrain.github.com/vcs-interoperability.html
>
> It was my first conference presentation so the usual caveats apply.
> I was fortunate to have a small but interested audience.
>
> I look forward to constructive criticism so that I can better represent
> our community to the folk Down Under.
Thanks for the valuable criticism. A few thoughts:
1. We'll try to fix this over the next few weeks.
2. Subversion's architecture is well-compartmentalized: is this what
leads to communication gaps between the API layers?
3. What are your thoughts on lib'ifying Git so that others can call
into it using an API?
Cheers!
^ permalink raw reply
* Re: Checkout tag?
From: Abscissa @ 2012-01-22 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <20120122101116.GA31022@jpl.local>
I saw that, but it seems to imply that it's not a simple:
>git checkout tag_name
because of the required <pathspec>, whatever that is.
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213061.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Checkout tag?
From: Nguyen Thai Ngoc Duy @ 2012-01-22 10:18 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327226753653-7213023.post@n2.nabble.com>
On Sun, Jan 22, 2012 at 5:05 PM, Abscissa <bus_nabble_git@semitwist.com> wrote:
> I've managed to figure out you switch branches with the checkout command,
> like this:
>
>>git checkout branch_name
>
> Does that work for tags as well? The docs don't seem clear on that. If not,
> how do you get the working copy to be a specific tag?
Magnus already answered your checkout question. I just want to add
that you can view a tag's content even without checking out. For
example,"git archive" can create a zip/tarball of any tree-ish. "git
ls-tree" lets you view directory structure of a tree-ish, "git show
<tree-ish>:path" lets you view content of a specific file.
--
Duy
^ permalink raw reply
* Re: Checkout tag?
From: Magnus Bäck @ 2012-01-22 10:11 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1327226753653-7213023.post@n2.nabble.com>
On Sunday, January 22, 2012 at 11:05 CET,
Abscissa <bus_nabble_git@semitwist.com> wrote:
> I've managed to figure out you switch branches with the checkout
> command, like this:
>
> >git checkout branch_name
>
> Does that work for tags as well? The docs don't seem clear on that.
> If not, how do you get the working copy to be a specific tag?
Yes, "git checkout" works for branches, tags, commit SHA-1s, and
anything else that can be resolved to a SHA-1 identifying what to
check out. The git-checkout(1) man page says the following:
git checkout [--patch] [<tree-ish>] [--] <pathspec>...
... The <tree-ish> argument can be used to specify a
specific tree-ish (i.e. commit, tag or tree) ...
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* Checkout tag?
From: Abscissa @ 2012-01-22 10:05 UTC (permalink / raw)
To: git
I've managed to figure out you switch branches with the checkout command,
like this:
>git checkout branch_name
Does that work for tags as well? The docs don't seem clear on that. If not,
how do you get the working copy to be a specific tag?
--
View this message in context: http://git.661346.n2.nabble.com/Checkout-tag-tp7213023p7213023.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Nguyen Thai Ngoc Duy @ 2012-01-22 10:03 UTC (permalink / raw)
To: Torsten Bögershausen, Junio C Hamano; +Cc: git
In-Reply-To: <CACsJy8BKQHLdoXfSKsULkWWbWjWEuZgr=bVNKmgCSArvwbf2UA@mail.gmail.com>
2012/1/22 Nguyen Thai Ngoc Duy <pclouds@gmail.com>:
>>> In order to prevent that ever a file name in decomposed unicode is
>>> entering the index, a "brute force" attempt is taken: all arguments into
>>> git (argv[1]..argv[n]) are converted into precomposed unicode.
Forgot one more thing. We have case-insensitive support in place
already, we can hook precomposed form conversion there before
comparing. In other words we just need to support
{pre,de}composed-insensitive string compare.
--
Duy
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Nguyen Thai Ngoc Duy @ 2012-01-22 9:58 UTC (permalink / raw)
To: Torsten Bögershausen, Junio C Hamano; +Cc: git
In-Reply-To: <7vsjj8acmh.fsf@alter.siamese.dyndns.org>
On Sun, Jan 22, 2012 at 5:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [Pinging Nguyen who has worked rather extensively on the start-up sequence
> for ideas.]
>
> Torsten Bögershausen <tboegi@web.de> writes:
>
> I'll try to reword the log message a bit below.
>
>> When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS" (in utf-8
>> encoded as 0xc3 0x84) is created, the Mac OS filesystem converts
>> "precomposed unicode" into "decomposed unicode". readdir() will return
>> 0x41 0xcc 0x88 for such a file, that does not match what the caller
>> thought it created.
>>
>> To work around this braindamage, allow git on Mac OS to optionally use a
>> wrapper for readdir() that converts decomposed unicode back into the
>> precomposed form, which most other platforms use natively. This makes it
>> easier for Mac OS users to work together on the same project with people
>> on other platforms (Note that not all Windows versions support UTF-8
>> yet. Msysgit needs the unicode branch, cygwin supports UTF-8 since
>> 1.7). This allows sharing git repositories stored on a VFAT file system
>> (e.g. a USB stick), and mounted network share using samba.
I just have a quick look, you reencode opendir, readdir, and
closedir() to precomposed form. But files are still in decomposed
form, does open(<precomposed file>) work when only <decomposed file>
exists?
>> In order to prevent that ever a file name in decomposed unicode is
>> entering the index, a "brute force" attempt is taken: all arguments into
>> git (argv[1]..argv[n]) are converted into precomposed unicode. This is
>> done in git.c by calling precompose_argv(). This function is actually a
>> #define, and it is only defined under Mac OS. Nothing is converted on
>> any other platforms.
This is not entirely safe. Filenames can be taken from a file for
example (--stdin option or similar). Unless I'm mistaken, all file
names must enter git through the index, the conversion at read-cache.c
may be a better option.
>> Auto sensing:
>> When creating a new git repository with "git init" or "git clone",
>> "core.precomposedunicode" will be set "false".
This is a general comment on init auto detection feature. Perhaps we
should allow detection to be done when reinitializing a repo. Or at
least make an option to auto detect, print out new config values and
user can decide if they want to change current values themselves.
>> +void precompose_argv(int argc, const char **argv)
>> +{
>> + int i = 0;
>> + const char *oldarg;
>> + char *newarg;
>> + iconv_t ic_precompose;
>> +
>> + git_config(precomposed_unicode_config, NULL);
>
> As the first thing called after main(), I still doubt this is a safe thing
> to do (Pinging Nguyen who has worked rather extensively on the start-up
> sequence for ideas). This is ifdefed away and will not break things on
> other platforms, which may make it even harder to diagnose breakages.
This can't be worse than current state of pager and alias settings,
which need to be detected even before setup_git_directory* is run.
I'd rather encode at index level and read_directory() than at argv[].
But if reencoding argv is the only feasible way, perhaps put the
conversion in parse_options()? Config reading is usually done by then,
and we can move precomposed config reading to git_default_config. If
some commands do not use parse_options yet, this is a good opportunity
to do so (I'll send pack-objects's parse_options() patch soon).
--
Duy
^ permalink raw reply
* [RFC/PATCH git-remote-bzr] Adapt to new semantics of remote-helper "import" command
From: Jonathan Nieder @ 2012-01-22 5:46 UTC (permalink / raw)
To: Gabriel Filion
Cc: git, Simon Poirier, Sverre Rabbelier, Jeff King, David Barr,
Dmitry Ivankov
Git 1.7.7 (commit 9504bc9d, "transport-helper: change import
semantics", 2011-07-16) incompatibly changed the interface of the
"import" capability.
Before, git would always send a single import command, which the
remote helper would respond to with a fast-import stream, terminated
by end of file, meaning there was no way to fetch multiple refs in one
connection. Nowadays, git instead sends a sequence of import lines:
import refs/heads/foo
import refs/heads/bar
terminated by a blank line. The helper is to respond with a
fast-import stream terminated by the "done" command and process
further commands until another blank line indicates the end of the
command stream.
---
Hi Simon and Gabriel,
Here's a rough patch against git://github.com/lelutin/git-remote-bzr.git
master.
Without this patch, whenever I try to use "git clone bzr::<something>",
after doing all the work it removes the resulting repo and exits with
status 141 (SIGPIPE). Maybe the transport-helper should mask SIGPIPE
when writing the final newline to avoid that.
I'd have prefered to write a patch for remote-bzr that works with
older versions of git fast-import, too, but it wasn't obvious how.
Hints welcome.
BTW, would you mind if I sent a patch to include git-remote-bzr in
git.git under contrib/?
Thanks for git remote-bzr! I'd be happy for any thoughts you have.
Ciao,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/176002/focus=176606
README.rst | 2 +-
git-remote-bzr | 33 ++++++++++++++++++++++++++++++---
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/README.rst b/README.rst
index 3eb3e476..f4dbbeb2 100644
--- a/README.rst
+++ b/README.rst
@@ -34,7 +34,7 @@ Relevant bug reports
Requirements
------------
-- git 1.6.6 or later
+- git 1.7.7 or later
- python 2.5 +
- bzr 2.x
- bzr-fastimport
diff --git a/git-remote-bzr b/git-remote-bzr
index 1e3a05f9..501fffe3 100755
--- a/git-remote-bzr
+++ b/git-remote-bzr
@@ -49,7 +49,7 @@ def do_list(repo, args):
print # end list
-def do_import(repo, args):
+def import_one_ref(repo, args):
"""Import a fast-import stream that is exported from Bazaar."""
if len(args) != 1:
die("Import needs exactly one ref")
@@ -65,6 +65,23 @@ def do_import(repo, args):
if bzrp.wait():
die("'bzr fast-export' returned unexpectedly with code %d",
bzrp.returncode)
+ print "done"
+
+
+def do_import(repo,args):
+ import_one_ref(repo, args)
+
+ cmdline = True
+ while cmdline:
+ cmdline = next_command()
+ if not cmdline:
+ # Return to main processing loop
+ return True
+ cmd = cmdline.pop(0)
+ if cmd != "import":
+ warn("Unexpected command %s during import" % cmd)
+ return False
+ import_one_ref(repo, cmdline)
def do_push(repo, args):
@@ -123,8 +140,8 @@ def sanitize(value):
return value
-def read_one_line(repo):
- """Read and process one command."""
+def next_command():
+ """Read one command."""
line = sys.stdin.readline()
cmdline = line
@@ -138,6 +155,16 @@ def read_one_line(repo):
# Blank line means we're about to quit
return False
+ return cmdline
+
+
+def read_one_line(repo):
+ """Read and process one command."""
+ cmdline = next_command()
+
+ if not cmdline:
+ return False
+
cmd = cmdline.pop(0)
debug("Got command '%s' with args '%s'", cmd, ' '.join(cmdline))
--
1.7.9.rc2
^ permalink raw reply related
* Re: Finding all commits which modify a file
From: Tay Ray Chuan @ 2012-01-22 4:03 UTC (permalink / raw)
To: Neal Groothuis; +Cc: git
In-Reply-To: <46043.208.70.151.129.1327095331.squirrel@mail.lo-cal.org>
On Sat, Jan 21, 2012 at 5:35 AM, Neal Groothuis <ngroot@lo-cal.org> wrote:
> Hello,
>
> I'm trying to find /all/ commits that change a file in the
> repository...and its proving to be trickier than I thought. :-)
>
> The situation that we were dealing with is this:
>
> - Person A and person B both pull from the same central repository.
>
> - Person A makes a change to file foo.txt and bar.txt, commits, and pushes
> to the central repository.
>
> - Person B makes a similar change to bar.txt and commits it.
>
> - Person B does a fetch and merge. Since both A and B made changes to
> bar.txt, this requires conflicts to be resolved manually.
>
> - B reverts A's changes to foo.txt. (If B is coming from a different
> revision control system, this may happen due to confusion about how merges
> are handled.)
How is this "revert" done? Was it done at the conflict resolution
level or with a git-revert invocation?
Nonetheless, either way, A's commit would be still be present in the
log history.
>[snip]
> Graphically:
>
> A1
> / ^
> v \
> C1 B2<-B3
> ^ /
> \ v
> B1
>
> B1, B2, and B3 have the same version of foo.txt as C1, A1 modifies it.
Just to clarify, is C1 the commit that both A and B both share when
they first pull in the first step? And B2 is the merge?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [linux.conf.au] VCS Interoperability
From: David Michael Barr @ 2012-01-22 3:39 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git, Junio C Hamano, Jonathan Nieder, Dmitry Ivankov
In-Reply-To: <CALkWK0kMmDMZ4wiMSmOfwBLzd+xBEA+WKsviu9FVcvj9eZEahg@mail.gmail.com>
Hi all,
>> Next week, I'll be presenting a summary of the past 2 years work
>> on improving svn interoperability for git.
>> I'm requesting feedback from anyone who cares with regard to
>> what they'd like to hear about.
>
> Nice. As a lay person attending the conference, here are a few things
> I think I'd like to hear:
> - Why this project is so challenging compared to say, a git-hg bridge
> or a git-darcs bridge. What makes Subversion especially hard to deal
> with?
> - What is the biggest motivation for developing the svnrdump/ svnrload
> combination? Are there any other usecases for the tools?
> - How has this project contributed to the development of the
> fast-import infrastructure? Can these changes be used to improve
> other/ future remote helpers?
> - You've spoken about exporting Subversion history to Git so far, but
> what about the reverse? Which parts of the picture are still missing?
Thank you for the feedback, it helped a lot with picking a trajectory.
Video is now available: http://youtu.be/0hVuv-wv4Dw
Slides: http://barrbrain.github.com/vcs-interoperability.html
It was my first conference presentation so the usual caveats apply.
I was fortunate to have a small but interested audience.
I look forward to constructive criticism so that I can better represent
our community to the folk Down Under.
--
David Barr
^ permalink raw reply
* Re: [PATCH] mergetool: Suppress stderr and fix the "both added" test
From: David Aguilar @ 2012-01-21 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jcwenger@gmail.com, git@vger.kernel.org
In-Reply-To: <7v39b8d9w6.fsf@alter.siamese.dyndns.org>
On Jan 21, 2012, at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> Silence error messages when "git checkout-index" is used to
>> checkout a stage that does not exist. This can happen now that
>> mergetool calls checkout_staged_file() unconditionally when
>> creating the temporary $BASE, $LOCAL, and $REMOTE files.
>>
>> Fix the test so that it checks the contents of the "both added"
>> file. The test was passing as a consequence of accidentally
>> handing a bad path to "cat".
>>
>> Signed-off-by: David Aguilar <davvid@gmail.com>
>> ---
>> This applies on top of da/maint-mergetool-twoway in pu.
>
> Thanks.
>
> It might make sense to squash this into the previous patch, which luckily
> hasn't hit 'next' yet, though---which I can do locally without need for
> re-send if you like.
Yes, please squash this commit. This is certainly a fix up.
Thanks,
David
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Neal Kreitzinger @ 2012-01-21 23:16 UTC (permalink / raw)
To: Neal Groothuis; +Cc: git
In-Reply-To: <46043.208.70.151.129.1327095331.squirrel@mail.lo-cal.org>
On 1/20/2012 3:35 PM, Neal Groothuis wrote:
> Hello,
>
> I'm trying to find /all/ commits that change a file in the
> repository...and its proving to be trickier than I thought. :-)
>
> The situation that we were dealing with is this:
>
> - Person A and person B both pull from the same central repository.
>
> - Person A makes a change to file foo.txt and bar.txt, commits, and pushes
> to the central repository.
>
> - Person B makes a similar change to bar.txt and commits it.
>
> - Person B does a fetch and merge. Since both A and B made changes to
> bar.txt, this requires conflicts to be resolved manually.
>
> - B reverts A's changes to foo.txt. (If B is coming from a different
> revision control system, this may happen due to confusion about how merges
> are handled.)
>
> - B commits the changes.
>
> - B makes more changes to bar.txt, commits them, and pushes to the central
> repository.
>
> At this point, A's changes to foo.txt have been undone.
>
> Graphically:
>
> A1
> / ^
> v \
> C1 B2<-B3
> ^ /
> \ v
> B1
>
> B1, B2, and B3 have the same version of foo.txt as C1, A1 modifies it.
>
> Person A discovers that his changes are missing and wants to know what
> happened.
>
> git log foo.txt doesn't help; it won't even show commit A1, due to history
> simplification.
>
> git log --full-history foo.txt will show commit A1. It still won't show
> commit B2, though, which we'd also like to show (because that's where the
> change to foo.txt got removed).
>
> I would think that git log --simplify-merges foo.txt would have done what
> I'd wanted, but it still does not show commit B2. Based on what I'm
> reading in the man page, I would expect the simplification to go like
> this:
>
> A1
> | ^
> | \
> | B2<-B3
> | /
> v v
> C1
>
> (since B1 is TREESAME as C1 if we're only considering foo.txt)
>
> A1
> | ^
> | \
> | B2<-B3
> |
> v
> C1
>
> (since C1 is an ancestor of A1)
>
> However, the actual output only includes A1, not B2.
>
> - Can someone explain this, and/or
> - can someone offer a command to display all commits (including merges)
> in which ANY parent is not TREESAME?
>
Does git-log --all help?
v/r,
neal
^ permalink raw reply
* Re: [PATCH V4] git on Mac OS and precomposed unicode
From: Junio C Hamano @ 2012-01-21 22:56 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <201201212036.57632.tboegi@web.de>
[Pinging Nguyen who has worked rather extensively on the start-up sequence
for ideas.]
Torsten Bögershausen <tboegi@web.de> writes:
I'll try to reword the log message a bit below.
> When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS" (in utf-8
> encoded as 0xc3 0x84) is created, the Mac OS filesystem converts
> "precomposed unicode" into "decomposed unicode". readdir() will return
> 0x41 0xcc 0x88 for such a file, that does not match what the caller
> thought it created.
>
> To work around this braindamage, allow git on Mac OS to optionally use a
> wrapper for readdir() that converts decomposed unicode back into the
> precomposed form, which most other platforms use natively. This makes it
> easier for Mac OS users to work together on the same project with people
> on other platforms (Note that not all Windows versions support UTF-8
> yet. Msysgit needs the unicode branch, cygwin supports UTF-8 since
> 1.7). This allows sharing git repositories stored on a VFAT file system
> (e.g. a USB stick), and mounted network share using samba.
>
> This new feature is controlled by setting a new configuration variable
> "core.precomposedunicode" to "true". Unless the variable is set to "true",
> Git on Mac OS behaves exactly as before, for backward compatiblity.
>
> The code in compat/precomposed_utf8.c implements basically 4 new
> functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
> precomposed_utf8_closedir() precompose_argv()
>
> In order to prevent that ever a file name in decomposed unicode is
> entering the index, a "brute force" attempt is taken: all arguments into
> git (argv[1]..argv[n]) are converted into precomposed unicode. This is
> done in git.c by calling precompose_argv(). This function is actually a
> #define, and it is only defined under Mac OS. Nothing is converted on
> any other platforms.
It may be just me, but the above looks more in line with the usual style
of writing in our existing log messages.
Is this UTF-8 decomposition only an issue on HFS+, or does it happen on
any filesystem mounted on a MacOS box? If the former, then the second line
of the first paragraph needs further rephrasing, e.g. "... is created,
HFS+, the primary filesystem on the Mac OS, converts ...".
> Auto sensing:
> When creating a new git repository with "git init" or "git clone",
> "core.precomposedunicode" will be set "false".
>
> The user needs to activate this feature manually.
> She typically sets core.precomposedunicode to "true" on HFS and VFAT,
> or file systems mounted via SAMBA onto a Linux box.
I am not sure about this design decision.
I agree that it is prudent to introduce a new feature disabled by default,
and I can understand that you tried to make the feature more discoverable
by setting it explicitly to "false".
But I do not think it is a good idea. If a user is on MacOS and has only
HFS+, then it would be more convenient to have the configuration set to
true in $HOME/.gitconfig once and for all, to affect all repositories on
the box. "git init" dropping the explicit "false" to any new repositories
defeats that.
Wouldn't it make more sense if your "git init" did it this way?
* Do not do anything, if you know core.precomposedunicode is already
set (in /etc/gitconfig or $HOME/.gitconfig);
* Otherwise, if the "probe" says "yes, we are on HFS+", issue an
advice message to suggest the user to set it either in the
repository specific .git/config or in $HOME/.gitconfig file.
> +core.precomposedunicode::
> + This option is only used by Mac OS implementation of git.
> + When core.precomposedunicode=true,
> + git reverts the unicode decomposition of filenames done by Mac OS.
> + This is useful when pulling/pushing from repositories containing utf-8
> + encoded filenames using precomposed unicode (like Linux).
I would imagine that if the caller of creat(2) named the path in the
decomposed form, Mac OS would store it unaltered; strictly speaking, we
shouldn't say "reverts". How about:
When set to true, pathnames in decomposed UTF-8 read from the
filesystem are converted to precomposed UTF-8 before they are used by
Git, to improve interoperability with other platforms.
> +void precompose_argv(int argc, const char **argv)
> +{
> + int i = 0;
> + const char *oldarg;
> + char *newarg;
> + iconv_t ic_precompose;
> +
> + git_config(precomposed_unicode_config, NULL);
As the first thing called after main(), I still doubt this is a safe thing
to do (Pinging Nguyen who has worked rather extensively on the start-up
sequence for ideas). This is ifdefed away and will not break things on
other platforms, which may make it even harder to diagnose breakages.
^ permalink raw reply
* Re: git clone, hardlinks and multiple users?
From: Neal Kreitzinger @ 2012-01-21 22:54 UTC (permalink / raw)
To: Marc Herbert; +Cc: git
In-Reply-To: <jfc8eh$ck5$1@dough.gmane.org>
On 1/20/2012 11:31 AM, Marc Herbert wrote:
> Hi,
>
> "git clone" is using hardlinks by default, even when cloning from a
> different user. In such a case the clone ends up with a number of
> files owned by someone else.
>
(I assume your using linux.) It sounds like you specified a url syntax
of /path/to/repo.git in your git-clone which tells git to use hardlinks.
If you want your own copies then specify file:///path/to/repo.git in
git-clone (see git-clone manpage section "GIT URLS":
http://schacon.github.com/git/git-clone.html).
> Since only immutable objects are cloned this seems to work fine.
> However I would like to know if this "multiple users" case works by
> chance or by specification.
>
(I'm not an expert on hardlinks, linux metadata, or git, and haven't
used hardlinks at all with linux or git yet, but do have some experience
with git and permissions.) I think if you plan your permissions to be
based on a primary group then it will "just work". If its not as simple
as a single primary group, then read on for my non-expert conversational
input, or at least skim thru for pointers to the reliable manpage
references...
It sounds like part of your question may actually be a hardlink
question so perhaps this info on hardlinks is useful:
http://linfo.org/hard_link.html to you. In regards to git, it does not
track metadata. However, it will track
"permissions" if you tell it to, but even then it only tracks the
executable bit to determine if its stored in the git repo as executable
or non-executable. If you are "changing" the metadata because you
modified the file contents (or executable bit) then
you are creating a new object (in git) and not modifying the original
hardlinked object (in git or linux) or its metadata (in linux). I
assume the working-tree (ie., WORKTREE/ of WORKTREE/.git repo) of the
clone is indeed a full copy of the files via git-checkout because the
manpage only claims to use hardlinks for the object store (ie.
.git/objects/) to save diskspace on the clone of the object store, not
the checkout of the worktree. Worktree objects only get written
to the object store if you stage them to the index (git-add). Then they
are stored in .git/objects/ according to the sha-1 of their
contents. Therefore, if your worktree copy has a different owner and
you don't modify the contents or executable bit then you can't possibly
stage it because git does not detect a difference in content or
executable bit. On the other hand, if you change the contents or the
executable bit then git will consider that a change and update the
object store, but it will be a new object and not the object
representing the previous version you hardlinked to when you cloned. If
that new object is then in turn pushed to the origin repo and someone
else clones it using hardlinks then they may very well not
be able to access that object if its owner:group excludes them. More
likely, if someone pushes an object with bad permissions then others
will get push errors because git stores objects in subdirs named after
the first two chars of the sha-1 which means other objects in that
subdir will also be inaccessible. If you change permissions in regard
to executable bit on your files without editing contents then I don't
know if git will make a new copy or modify the original inode because
I'm not sure if the executable bit permissions is represented in the
sha-1 contents or not. In the git-init manpage there are options for
permissions/sharing under the --shared option (not to be confused with
the --shared option of git-clone which it totally different). The
git-clone equivalent appears to be "git-clone --config
core.sharedRepository=<your-value>". Maybe these core.sharedRepository
settings in git are smart enough to handle the hardlink shared inode
metadata confusion.
> In other words, is there a guarantee that no later version of git or
> no obscure option I haven't used yet will ever try to touch a
> hardlink in any way like for instance: trying update some metadata
> timestamp or, overwrite it with the same value by lack of
> optimization, or any other kind of side-effect that would obviously
> fail.
>
However, if you cd to .git/objects/ and use chmod to change the
permission directly then I think it would change the permissions on the
inodes your origin is storing as loose objects. I'm not sure what it
would do for packed objects. There are clone options like --shared and
--reference that have special notes on the manpage explaining how you
could break things if you don't know what you're doing (that would
include hardlinks but is not exclusive to hardlinks).
Hope this helps in some way. Perhaps someone better informed will
provide a more accurate and/or clear answer. Let me know what
you find out because I too will have to become more concerned about
diskspace and clone optimization in the very near future.
v/r,
neal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox