Replies: 4 comments 1 reply
-
|
I have to check it out, but one thing I did notice in GitHub is that the newly-created tags have a recent date. I propose to back-date them so that they show up chronologically before the v3 tags. Maybe we can use the same date as the last commit it points to. From On Backdating Tags
If you have imported some changes from another VCS and would like to
add tags for major releases of your work, it is useful to be able to
specify the date to embed inside of the tag object; such data in the
tag object affects, for example, the ordering of tags in the gitweb
interface.
To set the date used in future tag objects, set the environment
variable GIT_COMMITTER_DATE (see the later discussion of possible
values; the most common form is "YYYY-MM-DD HH:MM").
For example:
$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
DATE FORMATS
The GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables
support the following date formats:
Git internal format
It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp>
is the number of seconds since the UNIX epoch. <time-zone-offset>
is a positive or negative offset from UTC. For example CET (which
is 1 hour ahead of UTC) is +0100.
RFC 2822
The standard date format as described by RFC 2822, for example Thu,
07 Apr 2005 22:13:13 +0200.
ISO 8601
Time and date specified by the ISO 8601 standard, for example
2005-04-07T22:13:13. The parser accepts a space instead of the T
character as well. Fractional parts of a second will be ignored,
for example 2005-04-07T22:13:13.019 will be treated as
2005-04-07T22:13:13.
Note
In addition, the date part is accepted in the following
formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the remark. I have deleted and recreated the tags. You can see the new ones at https://github.com/barijaona/vienna-rss/tags?after=v%2F3.0.0_beta8 If you previously imported my tags into your local repo, you'll need to delete and reimport them. |
Beta Was this translation helpful? Give feedback.
-
|
I find it difficult to understand what went wrong in the past and how you resolved it. To me it looks like the git history before Aug 2011 has every commit twice, one for the root path and one for the version path (e.g. For example, you have commits 6ee59be and 6161a37 which seem to do the same thing, but they apply the changes to different paths. Would it not be clearer to merge these commits and do away with the versioned paths or simply get rid of the commits with the versioned paths? I also wonder what happens to forks (will they have to pull and rebase?) and other branches, like |
Beta Was this translation helpful? Give feedback.
-
|
This could be an opportunity to move to the |
Beta Was this translation helpful? Give feedback.
-
6ee59be reflects the technical reality at that time. A problem when you do this is that you "cut" the history of files. There were also punctual errors which worsened the situation, like the initial attempt to create 2.2.0, or confusions between lowercase and uppercase letters in filenames. In August 2011, Michael Ströck decided to move from this structure having per branch subdirectories to a simpler one, in order to have the new developments occurring directly at the root directory. Once again, deletions followed by copies made git unable to retrieve earlier history. I don't know what features git had and were publicized at that time, but I guess things would have been a little better if he had used something like
My main motivation was to get comprehensive and understandable 
instead of this, where anything which occured before August 28th, 2011 is hidden: (Blames produced by tig, which you can install with Homebrew. Click the screenshots to have them more legible)
Indeed, we should get rid of the For good reasons, there is no way to force git to display a rewritten history without an explicit intervention of the end user. I will give a try to a larger use of |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
IMPORTANT: This could cause significant damage if I did something wrong.
Since I have worked on Vienna and tried to master Git, I was amazed by some changes which made it difficult to understand the code history.
It was only when I looked back to Vienna's history (here and there) that I understood the challenges that Michael Ströck had faced: moving from a directory structure inherited from SVN to one more suited to Git, while integrating work on Google Reader support that Adam Hartford had started on his own.
Unfortunately, some things went wrong:
This led me to look for Git techniques which could somehow repair the problems and rebuild a more legible history. You can see the result in my repository: I have created tags named
eol/2.0toeol/2.6that mark the end of work on the respective branches, and the forks between the different branches are now easily identifiable. I concluded this with areplacecommand so that my local git displays the reconstructed history for everything prior to August 2011:I also added a
repl/76d2a5b8tag to highlight the presence of this replacement.You can reproduce my work on your local repository by fetching the tags and replacements from my repo:
I also recommend removing tags
2.0.0through2.6.0in order to streamline the tree.The first lines of the output from
git blame -c Vienna/Sources/Application/AppController.millustrate the benefits: you can identify the lines that date back to Steve Palmer's initial commit:I intend to incorporate these changes into the ViennaRSS repository in a few days.
Beta Was this translation helpful? Give feedback.
All reactions